Jay Vosburgh wrote:
Or Gerlitz <[EMAIL PROTECTED]> wrote:
Sorry, but I don't follow... by saying "would be ideal to do ***it*** this
way in all cases" what exactly is the "it" you are referring to?
It refers to:
You almost want to have some kind of call to induce a reload
from scratch of the multicast filter settings (along with whatever else
might be necessary to alter the hardware type on the fly), to be called
by bonding at the time the first slave is added (since slave adds happen
in user context, and can therefore hold rtnl as required by most of the
multicast address handling code). That seems less hassle than having to
specify the hardware type and address length at module load time.
Having this would eliminate the need to specify the hardware
type at load time, and would allow changing of the hardware type at
enslave time, rather than at device up time. This requires fewer
changes to other things, like the initscripts or ifenslave.
The ideal would be to allow changing of hardware type at
literally any time, allowing failover across dissimilar hardware types.
That's a lot more complicated, and has a smaller pool of potential uses.
Thanks for the clarification. I would prefer first trying to go in the
direction you suggest below of changing the ifenslave program and the
kernel bonding code to allow for enslaving while the bonding device is
not UP.
1st, your current recommendation to solve the link layer address
computation of multicast groups joined by the stack before any enslavement
actually takes place, is to instrument the bonding code such that it would
be possible to enslave devices when the bonding device is not "up" yet.
2nd, the change need to be worked out in the bonding sysfs code, the
ifenslave program but ***also*** in packages such as /sbin/ifup and
friends.
Correct. The necessary changes to initscript and sysconfig are
probably the most complex piece to organize (not necessarily the hardest
to implement, but rather the most troublesome to deploy, as it
introduces an API change).
Looking on the sysconfig package, some tools eg /sbin/if{up,down,status}
use ifenslave which is in turn provided by the iputils package.
My understanding is that changing ifenslave and the bonding kernel code
to allow for enslaving while master is not up is enough, so actually no
change is needed to the sysconfig tools, correct?
I have now removed the two assertions in the bonding code on enslaving
while master is not up and manage to work fine with IPoIB slave devices
and ***without*** the two module params!
When you have the most troublesome to deploy, the troubles you refer to
is make sure that the distros would include ***both*** the bonding
kernel changes and use an iputils package which has the ifenslave changes?
Yes, ifenslave is still supported. It probably will be
obsoleted some day (or replaced with a script that uses sysfs), but not
anytime soon. As far as I know, all current distros use ifenslave to
configure bonding.
Cool, thanks for bringing this into my attention... I understand now my
patch set should also handle the ifenslave.c source that comes with the
kernel (eg to allow for not setting the hw address etc)
Or.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
