[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190727030223.GA29731@lunn.ch>
Date: Sat, 27 Jul 2019 05:02:23 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Allan W. Nielsen" <allan.nielsen@...rochip.com>
Cc: Horatiu Vultur <horatiu.vultur@...rochip.com>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
roopa@...ulusnetworks.com, davem@...emloft.net,
bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: bridge: Allow bridge to joing multicast groups
> As you properly guessed, this model is quite different from what we are used to.
Yes, it takes a while to get the idea that the hardware is just an
accelerator for what the Linux stack can already do. And if the switch
cannot do some feature, pass the frame to Linux so it can handle it.
You need to keep in mind that there could be other ports in the bridge
than switch ports, and those ports might be interested in the
multicast traffic. Hence the CPU needs to see the traffic. But IGMP
snooping can be used to optimise this. But you still need to be
careful, eg. IPv6 Neighbour discovery has often been broken on
mv88e6xxx because we have been too aggressive with filtering
multicast.
Andrew
Powered by blists - more mailing lists