From: Shmulik Hen <shmulik.hen@intel.com>
To: "Jay Vosburgh" <fubar@us.ibm.com>
Cc: <bonding-devel@lists.sourceforge.net>,
<bonding-announce@lists.sourceforge.net>, <netdev@oss.sgi.com>,
<linux-kernel@vger.kernel.org>, <linux-net@vger.kernel.org>,
"Jeff Garzik" <jgarzik@pobox.com>,
"Noam, Amir" <amir.noam@intel.com>,
"Mendelson, Tsippy" <tsippy.mendelson@intel.com>,
"Marom, Noam" <noam.marom@intel.com>
Subject: Re: [PATCH SET][bonding] cleanup
Date: Thu, 25 Sep 2003 20:07:05 +0300 [thread overview]
Message-ID: <200309252007.05642.shmulik.hen@intel.com> (raw)
In-Reply-To: <E791C176A6139242A988ABA8B3D9B38A02A464EF@hasmsx403.iil.intel.com>
On Thursday 25 September 2003 07:22 pm, Jay Vosburgh wrote:
> >patch 7 - eliminate the multicast_mode module param. settings are
> > now done only according to mode.
>
> This goes a bit beyond straight cleanup; could you explain
> the rationale for this change? Also, unless I'm missing something,
> the patch does not appear to update bonding.txt to reflect the fact
> that the module parameter is no more.
>
>
That question rings a bell :)
I had this discussion with Deniel Laurent on 8/30 and it sounded like
that wouldn't be a problem after all.
[from that thread]
> Do you know that this breaks upward compatibility ?
[snip]
> But if everyone is OK ... (I'd be since I currently only use
> multicast_mode = 1 ;-).
The rationale is that the propagation code already made this module
param obsolete, so the next step was to remove it entirely since it
had no effect anyway.
According to the propagation RFC we sent on 2/6, multicast list,
allmulti flag and promisc flag are all controlled the same way, and
that is according to the USES_PRIMARY macro. When the bond uses the
current slave as a primary interface, it, and only it, is supposed to
have the bond's properties, while in aggregation modes all slaves
have the same settings. There is no point in settings other slaves,
that are not supposed to be receiving in the first place, to have
loose filtering. Otherwise the stack will be flooded by duplicate
packets. The situation is bad enough now since bonding has no
solution for broadcast packets, but that's for another thread.
--
| Shmulik Hen Advanced Network Services |
| Israel Design Center, Jerusalem |
| LAN Access Division, Platform Networking |
| Intel Communications Group, Intel corp. |
next parent reply other threads:[~2003-09-25 17:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E791C176A6139242A988ABA8B3D9B38A02A464EF@hasmsx403.iil.intel.com>
2003-09-25 17:07 ` Shmulik Hen [this message]
2003-09-25 12:49 [PATCH SET][bonding] cleanup Shmulik Hen
2003-09-25 16:22 ` Jay Vosburgh
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=200309252007.05642.shmulik.hen@intel.com \
--to=shmulik.hen@intel.com \
--cc=amir.noam@intel.com \
--cc=bonding-announce@lists.sourceforge.net \
--cc=bonding-devel@lists.sourceforge.net \
--cc=fubar@us.ibm.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=noam.marom@intel.com \
--cc=tsippy.mendelson@intel.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).