From: Jay Vosburgh <fubar@us.ibm.com>
To: Weiping Pan <panweiping3@gmail.com>
Cc: Andy Gospodarek (supporter:BONDING DRIVER) <andy@greyhouse.net>,
netdev@vger.kernel.org (open list:BONDING DRIVER),
linux-kernel@vger.kernel.org (open list)
Subject: Re: [PATCH net V3] bonding: send igmp report for its master
Date: Thu, 15 Mar 2012 20:43:19 -0700 [thread overview]
Message-ID: <31016.1331869399@death.nxdomain> (raw)
In-Reply-To: <3072c40712c2f5506fc57937da921da0d3d83450.1331778582.git.panweiping3@gmail.com>
Weiping Pan <panweiping3@gmail.com> wrote:
>Liang Zheng(lzheng@redhat.com) found that in the following topo,
>bonding does not send igmp report when we trigger a fail-over of bonding.
>
>eth0--
> |-- bond0 -- br0
>eth1--
>
>modprobe bonding mode=1 miimon=100 resend_igmp=10
>ifconfig bond0 up
>ifenslave bond0 eth0 eth1
>
>brctl addbr br0
>ifconfig br0 192.168.100.2/24 up
>brctl addif br0 bond0
>
>Add 192.168.100.2(br0) into a multicast group, like 224.10.10.10,
>then trigger a fali-over in bonding.
>You can see that parameter "resend_igmp" does not work.
>
>The reason is that when we add br0 into a multicast group,
>it does not propagate multicast knowledge down to its ports.
>
>If we choose to propagate multicast knowledge down to all ports for bridge,
>then we have to track every change that is done to bridge, and keep a backup
>for all ports. It is hard to track, I think.
>
>Instead I choose to modify bonding to send igmp report for its master.
>
>Changelog:
>V2: correct comments
>V3: move this check into bond_resend_igmp_join_requests()
>
>Signed-off-by: Weiping Pan <panweiping3@gmail.com>
>---
> drivers/net/bonding/bond_main.c | 14 +++++++++++---
> 1 files changed, 11 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 435984a..037fdd3 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -766,18 +766,26 @@ static void __bond_resend_igmp_join_requests(struct net_device *dev)
> */
> static void bond_resend_igmp_join_requests(struct bonding *bond)
> {
>- struct net_device *vlan_dev;
>+ struct net_device *bond_dev, *vlan_dev, *master_dev;
> struct vlan_entry *vlan;
>
> read_lock(&bond->lock);
>
>+ bond_dev = bond->dev;
>+
> /* rejoin all groups on bond device */
>- __bond_resend_igmp_join_requests(bond->dev);
>+ __bond_resend_igmp_join_requests(bond_dev);
>+
>+ /* rejoin all groups on its master */
>+ master_dev = bond_dev->master;
>+ if (unlikely(master_dev)) {
>+ __bond_resend_igmp_join_requests(master_dev);
>+ }
Will this do the right thing if the master is not a bridge?
Granted, right now the only other possible master is a team (since
bonding will not enslave itself), but is this generically safe and
desirable for any possible master_dev?
-J
> /* rejoin all groups on vlan devices */
> list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
> rcu_read_lock();
>- vlan_dev = __vlan_find_dev_deep(bond->dev,
>+ vlan_dev = __vlan_find_dev_deep(bond_dev,
> vlan->vlan_id);
> rcu_read_unlock();
> if (vlan_dev)
>--
>1.7.4.4
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
next prev parent reply other threads:[~2012-03-16 3:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 8:40 [PATCH net] bonding: send igmp report for its master Weiping Pan
2012-03-14 13:58 ` [PATCH net V2] " Cong Wang
2012-03-14 17:22 ` Andy Gospodarek
2012-03-15 3:11 ` [PATCH net V3] " Weiping Pan
2012-03-16 3:43 ` Jay Vosburgh [this message]
2012-03-16 13:38 ` Andy Gospodarek
2012-03-18 3:23 ` [PATCH net V4] " Weiping Pan
2012-03-19 22:06 ` David Miller
2012-03-17 5:58 ` [PATCH net V2] " David Miller
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=31016.1331869399@death.nxdomain \
--to=fubar@us.ibm.com \
--cc=andy@greyhouse.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=panweiping3@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.