Dear kernel maintainers,
We are sending you this email to a) introduce ourselves, and b) discuss
with you some proposed changes for channel bonding. We want to make sure
that any new features that we add will be accepted into the kernel, so
we felt it was important to discuss design issues with you prior to
actually implementing the changes.
First, introductions: Radheka and Mitch are Intel's new channel bonding
team. We have been given the job of maintaining and enhancing channel
bonding, with the goal of giving it a feature set that is comparable
with our iANS product, which we can then retire. Radheka has done
extensive work on our Windows ANS component, so she knows a bunch about
how the various teaming modes work. Mitch has extensive Linux
experience, and currently owns Linux iANS.
Second, proposed changes (mostly copied from our requirements doc):
At this time using multiple teams with bonding is problematic. It is
possible to load the bonding module with a command-line parameter to
create multiple teams, but these teams will all have exactly the same
parameters and functionality. In other words, when loading the module in
this fashion, you can't have one team in 802.3AD mode, and another team
in AFT mode.=20
Alternately, the bonding driver may be loaded multiple times. This
allows the user to have teams with different parameters, but requires
more gyrations in the system configuration files, and wastes memory.
The following 2 features would address the above issues:
1] Re-configure bond Mode and Parameters at runtime=20
To address this, we would allow configuration changes to a given bonding
interface by implementing a socket (e.g. SIOCBONDDEVICE) ioctl
In other words, to reconfigure bond0 to a different teaming mode, you
would send an ioctl to bond0 telling it to do so. This (obviously) will
require changes to both ifenslave and the module itself.
We really don't feel that this design will be problematic, but wanted to
double-check with you anyway.
2] Add/Delete teams at runtime=20
Following are possible designs for this:=20
a)IOCTL to Any Bonding Interface=20
Open a socket on any available bonding interface and send configuration
ioctls to the driver.
While this scheme would be workable, there are some issues:=20
- How does ifenslave decide which interface to use?
- What if the user tries to delete the interface that ifenslave is using
- What happens if the user deletes all of the interfaces? There's no way
to add a new one!
b)IOCTL to Dummy Bonding Interface The bonding module would create a
dummy network interface that is used only for configuration; no traffic
is passed on this interface and any attempt to do so fails. Since the
interface has a fixed name, and since it isn't part of a bond, it
handles the case of having no active bonds. Our iANS product uses this
method for configuration, so we know that it works.
The drawback is that this technique can be confusing to users. Why is
there an interface available that can't be used for traffic?
c)IOCTL to Dummy Character Driver=20
Bonding would implement a character device interface that would accept
ioctls. While this would work, it seems a bit ...weird. Why would a
network module be configured through a character device?
Bonding would implement one or more "files" in the sysfs virtual file
system. Configuration would be accomplished by writing data to these
files. The logical consequence of this scheme seems to suggest that
ifenslave could be completely deprecated if we wanted.
The disadvantage of this scheme is that it would take extra work for
users of the 2.4 kernel, which does not have sysfs enabled by default.=20
One more problem would be if you have two user-mode applications both
trying to do something with a sysfs node, there is a race between the
applications with respect to the return code, assuming the return code
is being returned from the sysfs "show" function (for e.g. user-mode
applications like "echo", if you consider that an application).=20
However, you can get around the problem by using file i/o operations
like open /write/read/close within a C application, since the open for
write access will block any other applications. So this will prevent the
We feel that the best way to implement this feature is to use the sysfs
interface, but would appreciate your input on this issue. As we stated
above, we don't want to spendte our time implementing code that will not
be accepted into the kernel.
Once we have an agreement on the preferred method to address issue 2] we
can begin work on updating bonding.
Thank you for your time,=20