[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210128032726.GP1421720@Leo-laptop-t470s>
Date: Thu, 28 Jan 2021 11:27:26 +0800
From: Hangbin Liu <liuhangbin@...il.com>
To: Nikolay Aleksandrov <nikolay@...dia.com>
Cc: netdev@...r.kernel.org, Roopa Prabhu <roopa@...dia.com>,
"David S . Miller" <davem@...emloft.net>,
bridge@...ts.linux-foundation.org, Jarod Wilson <jarod@...hat.com>,
Jiri Pirko <jiri@...nulli.us>,
Ivan Vecera <ivecera@...hat.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Ido Schimmel <idosch@...sch.org>
Subject: Re: [PATCH net-next] bridge: Propagate NETDEV_NOTIFY_PEERS notifier
On Wed, Jan 27, 2021 at 11:43:30AM +0200, Nikolay Aleksandrov wrote:
> > For IGMP, although you said they are different. In my understanding, when
> > bridge mac changed, we need to re-join multicast group, while a gratuitous
> > ARP is also needed. I couldn't find a reason why IGMP message is OK but GARP
> > is not.
> >
>
> I think that's needed more because of port changing rather than mac changing.
> Switches need to be updated if the port has changed, all of that is already handled
> correctly by the bond. And I also meant that mcast is handled very differently in
> the bridge, usually you'd have snooping enabled.
>
> The patch below isn't correct and will actually break some cases when bonding
> flaps ports and propagates NETDEV_RESEND_IGMP with a bridge on top.
Hi Nikolay,
I'm little curious. bond/team device will resend IGMP as their MAC address changed.
- bond_resend_igmp_join_requests_delayed()
- call_netdevice_notifiers(NETDEV_RESEND_IGMP, bond->dev);
- team_mcast_rejoin_work()
- call_netdevice_notifiers(NETDEV_RESEND_IGMP, team->dev);
What's the purpose that bridge resend IGMP if it's mac address not changed?
I mean, when there is a bridge on top of bond/team, when bond/team flap ports,
bond/team will re-send IGMP and bridge just need to forward it. bridge doesn't
need to re-send the IGMP itself if it's MAC address not changed.
Thanks
Hangbin
Powered by blists - more mailing lists