If you change the mtu at a later time you need to go through all the slaves
and change it there manually also. There is down propagation only if you set
things in the master before the slaves are enslaved (or if you re-enslave
them after the changes).
OTOH, you can eliminate the hard limits that I used (although they pretty
much cover every piece of hardware available). I just put them for sanity so
that nobody tried a crazy mtu like 2 or 100000.
Regards,
Flavio
-----Original Message-----
From: Jay Vosburgh [mailto:fubar@...]
Sent: Friday, March 07, 2003 2:04 PM
To: Villanustre, Flavio
Cc: bonding-devel@...
Subject: RE: [Bonding-devel] Variable MTU for Bonding device (Jumbo Frames
support)
What happens if you want to change the mtu at a later time? I'm
thinking about cases, for example, of an active-backup bond wherein the
backup link's mtu may differ from the primary's (a gigabit link backed up
by a 10/100, for example). Or just the general case of people tweaking the
mtus or other ifconfig data. That's probably outside the scope of what
you're worried about, though.
And, I probably shouldn't have used mtu as my example, because it can
be done reliably via the bonding device's change_mtu function (have it
cycle through all of the slaves and change each of their mtus in turn). My
comment about the methodology (call chain notifiers) is still true for the
other data, netmask, address, etc. In any event, for the mtu case, pushing
it down to the slaves eliminates any hard-coded mtu limits within bonding
itself.
-J
"Villanustre, Flavio" <FVillanustre@...> on 03/07/2003 10:54:49 AM
To: Jay Vosburgh/Beaverton/IBM@..., "Villanustre, Flavio"
<FVillanustre@...>
cc: bonding-devel@...
Subject: RE: [Bonding-devel] Variable MTU for Bonding device (Jumbo
Frames support)
No, you don't have to change the mtu of each slave individually as long as
you configure the mtu in the bonding device before enslaving them. If you
do
that the other way around, then you do need to change the slaves manually.
So, this patch is an easy implementation that follows the guidelines in the
bonding device documentation (i.e. configure everything in the bonding
device before enslaving the interfaces and the changes will propagate to
them).
Regards,
Flavio Villanustre
-----Original Message-----
From: Jay Vosburgh [mailto:fubar@...]
Sent: Friday, March 07, 2003 1:49 PM
To: Villanustre, Flavio
Cc: bonding-devel@...
Subject: Re: [Bonding-devel] Variable MTU for Bonding device (Jumbo Frames
support)
I'm currently about half way through a patch to make all of the
ifconfig stuff (flags, promisc, mtu, addresses, etc) propogate from the
master down to the slaves; I should have a first draft ready for some
initial public inspection early next week.
Anyway, part of that is dealing with mtu changes to the master
propogating down. My thought at the moment for mtu stuff is to have no
explicit mtu limit for the master itself, and have changes make their way
to the slaves (via the notifier call chains). The slaves would apply their
own change_mtu function, which would either succeed or fail on its own.
Right now, I've got the mtu part working to the point that changes
propogate down, but errors at the slave level don't go back up (which is
difficult to do, because, e.g., the SIOCIFMTU handler in dev_ifsioc()
doesn't check the return value from notifier_call_chain(), and even if it
did, it's not clear what the proper recovery action is).
With your patch applied, do you still have to change the mtu of each
slave individually, in addition to the the master?
-J
"Villanustre, Flavio" <FVillanustre@... on
03/07/2003 10:11:58 AM
Sent by: bonding-devel-admin@...
To: bonding-devel@...
cc:
Subject: [Bonding-devel] Variable MTU for Bonding device (Jumbo Frames
support)
Dear all,
I needed to support Jumbo Frames in the bonding device (as we already use
jumbo frames with the tg3 driver). So I created this small patch against
the
standard bonding device supported by kernel 2.4.20, and I thought that this
could be useful for others as well. Do you think you can include it into
the
main bonding driver source tree?
Thanks,
Flavio Villanustre
----------------------------------------------------------------------------
---------------------------
--- bonding.c.backup Fri Mar 7 08:15:31 2003
+++ bonding.c Fri Mar 7 09:46:07 2003
@@ -307,6 +307,9 @@
/* #define BONDING_DEBUG 1 */
+#define BONDING_MIN_MTU 64
+#define BONDING_MAX_MTU 9252
+
/* several macros */
#define IS_UP(dev) ((((dev)->flags & (IFF_UP)) == (IFF_UP)) && \
@@ -2154,6 +2157,23 @@
return len;
}
+static int bonding_change_mtu(struct net_device *dev, int new_mtu)
+{
+ if (new_mtu < BONDING_MIN_MTU || new_mtu > BONDING_MAX_MTU)
+ return -EINVAL;
+
+ if (!netif_running(dev)) {
+
+ dev->mtu = new_mtu;
+ return 0;
+ }
+
+ dev->mtu = new_mtu;
+ return 0;
+}
+
static int bond_event(struct notifier_block *this, unsigned long event,
void *ptr)
{
@@ -2263,6 +2283,7 @@
dev->tx_queue_len = 0;
dev->flags |= IFF_MASTER|IFF_MULTICAST;
+ dev->change_mtu = bonding_change_mtu;
#ifdef CONFIG_NET_FASTROUTE
dev->accept_fastpath = bond_accept_fastpath;
#endif
----------------------------------------------------------------------------
---------------------------
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. http://www.etnus.com
_______________________________________________
Bonding-devel mailing list
Bonding-devel@...
https://lists.sourceforge.net/lists/listinfo/bonding-devel
|