On Thu, Jan 13, 2022 at 09:07:51AM +0100, Karsten Graul wrote:
>>> One comment to sysctl: our current approach is to add new switches to the existing
>>> netlink interface which can be used with the smc-tools package (or own implementations of course).
>>> Is this prereq problematic in your environment?
>>> We tried to avoid more sysctls and the netlink interface keeps use more flexible.
>>
>> I agree with you about using netlink is more flexible. There are
>> something different in our environment to use netlink to control the
>> behaves of smc.
>>
>> Compared with netlink, sysctl is:
>> - easy to use on clusters. Applications who want to use smc, don't need
>> to deploy additional tools or developing another netlink logic,
>> especially for thousands of machines or containers. With smc forward,
>> we should make sure the package or logic is compatible with current
>> kernel, but sysctl's API compatible is easy to discover.
>>
>> - config template and default maintain. We are using /etc/sysctl.conf to
>> make sure the systeml configures update to date, such as pre-tuned smc
>> config parameters. So that we can change this default values on boot,
>> and generate lots of machines base on this machine template. Userspace
>> netlink tools doesn't suit for it, for example ip related config, we
>> need additional NetworkManager or netctl to do this.
>>
>> - TCP-like sysctl entries. TCP provides lots of sysctl to configure
>> itself, somethings it is hard to use and understand. However, it is
>> accepted by most of users and system. Maybe we could use sysctl for
>> the item that frequently and easy to change, netlink for the complex
>> item.
>>
>> We are gold to contribute to smc-tools. Use netlink and sysctl both
>> time, I think, is a more suitable choice.
>
>Lets decide that when you have a specific control that you want to implement.
>I want to have a very good to introduce another interface into the SMC module,
>making the code more complex and all of that. The decision for the netlink interface
>was also done because we have the impression that this is the NEW way to go, and
>since we had no interface before we started with the most modern way to implement it.
>
>TCP et al have a history with sysfs, so thats why it is still there.
>But I might be wrong on that...
Sorry to bother on this topic again...
When implementing SMC autocork, I'd like to add a switch to enable or
disable SMC autocork just like what TCP does. But I encounter some
problem which I think might be relevant to this topic.
My requirements for the switch is like this:
1. Can be set dynamically by an userspace tool
2. Need to be namespacified so different containers can have their own
value
3. Should be able to be configured to some default values using a
configuration file so every time a container started, those values can
be set properly.
I notice we have a patch recently("net/smc: Add global configure for
handshake limitation by netlink") which did something similar. And I
tried the same way but found it might not be very elegant:
1. I need to copy most of the code(enable/disable/dump) for autocork
which is quite redundant. Maybe we should add some common wrappers ?
2. I need to add a new enumeration, and what if years later, we found
this function is no longer need ? Deleting this may cause ABI
compatibility issues
3. Finally, How can we implement requirement #3 ? It is really needed
in the K8S container environment.
Any suggestions or comments are really welcomed.
Thanks!
