netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Or Gerlitz <ogerlitz@voltaire.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: netdev@vger.kernel.org, Roland Dreier <rdreier@cisco.com>
Subject: Re: [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices
Date: Thu, 05 Oct 2006 16:56:46 +0200	[thread overview]
Message-ID: <45251D2E.7050006@voltaire.com> (raw)
In-Reply-To: <200610041734.k94HYEZt013562@death.nxdomain.ibm.com>

Jay Vosburgh wrote:
> Or Gerlitz <ogerlitz@voltaire.com> wrote:
>> 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?
> 
> 	Incorrect.  The /sbin/ifup included with sysconfig (I'm looking
> at version 0.31-0-15.51) has logic to set the bonding master device up
> prior to adding any slaves.  E.g.,
> 
> 		# 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`
> 
> 	For your purposes, this would cause it to register as an
> ethernet hardware type, not an IB type.  The /sbin/ifup included with
> initscripts operates a little differently, but also sets the bonding
> master up prior to adding any slaves.

OK, you are correct, i agree that the /sbin/ifup would attempt to first 
bring up the bonding device so it breaks my assumptions...

> 	Yes.  Part of the difficulty is that the changes to the
> initscripts and sysconfig packages won't be compatible with versions of
> bonding prior to the bonding kernel changes (because older versions of
> bonding will refuse to add slaves if the master is down).  It might
> require adding another API version to bonding, and modifying ifenslave
> to work both ways (i.e., with the current "enslave with master up" API,
> as well as the new "enslave with master down" API).

Gee, sounds bad

> 	An alternate approach would be to undertake the more substantial
> task of converting the initscripts and sysconfig code to use sysfs to
> configure bonding.  This would permit changing the logic (to add slaves
> while the bonding master is down, then set it up), as well as remove the
> current hacks (present only in sysconfig) to load the bonding module
> once per configured bonding interface.  The initscripts currently don't
> do this (as far as I know), so it's generally only possible to have one
> bonding interface under initscripts control.

This sounds like a good idea to get out of all these troubles...

So the direction to have sysconfig and initscripts tools configure 
bonding by sysfs and not by the enslave program is something you were 
considering regardless of the needs imposed by bonding support for non 
ARPHRD_ETHER netdevices? and you think the distro packages owners would 
like this?

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.

Basically, i use now my own script working with sysfs in my IPoIB 
bonding testing where i have followed the directions in the bonding 
kernel doc.

Thanks again for all the coaching...

Or.



  reply	other threads:[~2006-10-05 14:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-26 10:16 [RFC][PATCH 0/3] bonding support for operation over IPoIB Or Gerlitz
2006-09-26 10:17 ` [RFC][PATCH 1/3] enable bonding to enslave non ARPHRD_ETHER netdevices Or Gerlitz
2006-09-26 19:23   ` Jay Vosburgh
2006-09-27 19:59     ` Or Gerlitz
2006-09-28 17:02       ` Jay Vosburgh
2006-10-03 12:56         ` Or Gerlitz
2006-09-26 10:17 ` [RFC][PATCH 2/3] enable bonding to enslave netdevices not supporting set_mac_address() Or Gerlitz
2006-09-26 10:18 ` [RFC] [PATCH 3/3] enable IP multicast when bonding IPoIB devices Or Gerlitz
2006-09-26 17:05   ` Stephen Hemminger
2006-09-27 20:16     ` Or Gerlitz
2006-09-26 23:40   ` Jay Vosburgh
2006-09-27 20:12     ` Or Gerlitz
2006-09-28 17:43       ` Jay Vosburgh
2006-10-03 13:06         ` Or Gerlitz
2006-10-03 23:10           ` Jay Vosburgh
2006-10-04 15:25             ` Or Gerlitz
2006-10-04 17:34               ` Jay Vosburgh
2006-10-05 14:56                 ` Or Gerlitz [this message]
2006-10-05 18:13                   ` Jay Vosburgh
2006-10-09 13:15                     ` Or Gerlitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45251D2E.7050006@voltaire.com \
    --to=ogerlitz@voltaire.com \
    --cc=fubar@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdreier@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).