Re: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices

[Or Gerlitz <ogerlitz@voltaire.com>]

Jay Vosburgh wrote:
> 	After some reflection, I suspect it wouldn't be all that awful.
> The main concern is going to be whether or not the existing ifenslave
> binaries supplied with distros will run with the new version of bonding.
> Since the new version of bonding that you're proposing is really just
> relaxing the rules (rather than imposing a different, incompatible set
> of rules), that's probably not a really big deal.  I don't think it
> would require a revision change to the bonding ifenslave API.

Indeed, makes sense, the modified bonding driver would work with old 
ifenslave binaries.

> 	Yes, the long term direction is to have the initscripts
> configure bonding via sysfs, either directly or via the step of
> converting ifenslave to a script that uses sysfs.  

> 	I personally find ifenslave to be more convenient to use than
> repeated "echo whatever > /sys/this/that/the/other", but there's no
> reason that ifenslave couldn't do the various echo things itself under
> the covers.  

> 	One drawback to sysfs is that there's no real-time error
> reporting; you have to look at dmesg to see if your request succeeded or
> not.  I'm not sure offhand if, e.g., adding a sysfs file to bonding for
> "last-request-status" is a kosher sysfs thing to do; if it is, then an
> ifenslave script could check such a thing to figure out error returns.

Can you check that with someone around?

> 
> 	It seems more logical to me to embed all of the bonding sysfs
> magic stuff into a separate script, but the maintainers of initscipts or
> sysconfig may see things differently.
> 
> 	The main advantage to either of these (initscripts/sysconfig
> and/or ifenslave converted to sysfs) is that it eliminates the need to
> load the bonding driver module multiple times to have more than one
> bonding device with differing module parameters (because the sysfs
> interface can create any number of bonding interfaces with arbitrary
> settings).
> 
>> I will look into the current methods used by sysconfig to configure
>> bonding and see if i can come up with sketch of how to do it with sysfs.
> 
> 	It's probably easier to first convert ifenslave to a sysfs-using
> script that the existing initscripts can use.  
> 
> 	This allows the changes to be published in stages, rather than
> requiring a single flag day changeover.  The first stage changes the
> bonding driver itself to permit enslavement with the master down
> (insuring that existing ifenslave binaries supplied with reasonably
> current distros continue to function).  Next, ifenslave is changed to
> use sysfs (simultaneously removing the adjustment of the master or
> slave's up/down state during enslavement).  The next stage either
> changes the initscripts/sysconfig to use sysfs directly or change its
> use of ifenslave to not do multiple loads of the bonding driver. 

This plan makes much sense! however, this way or another (ie whether 
sysconfig tools are modified to use sysfs or ifenslave becomes a script 
that uses sysfs) there should be a change to sysconfig tools 
(specifically /sbin/ifup) in the place where it first makes the bonding 
interface UP and only later enslave the slave devices (eg the quote 
below from /sbin/ifup of sysconfig-0.50.9-13.8 that comes with SLES10)
correct?

>                 # get up the bonding device before enslaving
> #               if ! is_iface_up $INTERFACE; then
>                         ip link set $INTERFACE up 2>&1
> #               fi
>                 # enslave available slave devices; if there is none -> hard break and log
>                 MESSAGE=`/sbin/ifenslave $BONDING_OPTIONS $INTERFACE $BSINTERFACES 2>&1`

So this becomes the forth step on the plan. And the most fragile aspect 
of the plan is the fact that ***two*** packages need to be changed as 
/sbin/ifenslave is not part of sysconfig but rather of (eg on SLES10)
iputils-ss021109-167.2

Or.