Message-ID: <Z7-TBwv6iDY-1uAm@sellars>
Date: Wed, 26 Feb 2025 23:17:43 +0100
From: Linus Lüssing <linus.luessing@...3.blue>
To: Nikolay Aleksandrov <razor@...ckwall.org>
Cc: Joseph Huang <joseph.huang.2024@...il.com>,
	Vladimir Oltean <olteanv@...il.com>,
	Joseph Huang <Joseph.Huang@...min.com>, netdev@...r.kernel.org,
	Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <f.fainelli@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Roopa Prabhu <roopa@...dia.com>, linux-kernel@...r.kernel.org,
	bridge@...ts.linux.dev, Jan Hoffmann <jan@....eu>,
	Birger Koblitz <git@...ger-koblitz.de>,
	Sebastian Gottschall <s.gottschall@...wrt.com>
Subject: Re: [PATCH RFC net-next 00/10] MC Flood disable and snooping

On Wed, Feb 26, 2025 at 09:20:58PM +0100, Linus Lüssing wrote:
> [...]
> The main issue seems that the learned or manually set multicast
> router ports in the Linux bridge are not propagated down to the
> actual multicast offloading switches.

Next to this issue I'm also wondering if the following might still
need addressing (which this patchset does not try to address?) to
support multicast offloading switches with kernelspace
IGMP/MLD snooping - or if there are some switch chips which do
not support this and hence won't be able to use kernelspace
IGMP/MLD snooping. A rough first attempt of a guideline/checklist:

Needed switch chip capabilities:

1) adding MDB entries to ports
2) adding multicast router ports
3) -> the switch chip must only apply these to
        a) IP packets with a matching protocol family
	   (ether type 0x0800 || 0x86DD) and:
        b.1) snoopable IP multicast address ranges
           (224.0.0.0/4 minus 224.0.0.0/24,
	    ff00::/8 minus ff02::1/128
	    IP destination addresses)
	   b.2) alternatively to b.1 (+a), but less
	   desirably a switch chip might match on layer 2:
	   01:00:5E:00:00:00, mask ff:ff:ff:f8:00:00
	   minus 01:00:5e:00:00:00, mask ff:ff:ff:ff:ff:00;
	   33:33:00:00:00:00, mask ff:ff:00:00:00:00
	   minus 33:33:00:00:00:01, mask ff:ff:ff:ff:ff:ff
	c.1) must *not* apply this to IGMP/MLD reports
	   (especially IGMPv1/v2/MLDv1 reports), they
	   must only be forwarded to the registered
	   multicast router ports *plus*
	   the CPU port / Linux bridge,
	   for the latter to be able to learn
	   c.2) may forward IGMP/MLD packets
	   only to the CPU port / Linux bridge,
	   if the Linux bridge (or DSA) can in turn
	   selectively forward the IGMP/MLD
	   to multicast router ports,
	   excluding the incoming port
	   -> DSA might need to inform the
	      Linux bridge about the
	      supported mode of the switch chip?
	(d) IGMP/MLD queries need to be flooded to
	   all ports by default, but they would not
	   match 3.b or 3.c.1 anyway; 3.c.2 may
	   match, then the Linux bridge (or DSA)
	   needs to make sure to reflect it back
	   to all ports excluding the incoming port
4) Any frame that did not match via 3) within the
   switch chip must by default be flooded to all ports
   4.1) this should be tunable and propagated from
        Linux bridge MCAST_FLOOD port flag to the
	switch chip
   4.2) if a switch chip cannot comply with 3) and
        has bridge port isolation enabled then
	the Linux bridge should perform multicast
	forwarding and IGMP/MLD snooping fully
	in kernelspace and return a warning
	about missing hardware support
   4.3) if a switch chip cannot adhere to neither 3) nor 4.2)
        then a user trying to enable bridge multicast snooping
	should be denied and return an error
	=> no incomplete hacks allowed, which might break
	   especially IP in specific scenarios


Would it maybe make sense to add some guideline/checklist like this,
which is more explicit than RFC4541 but should be compatible
to it, to Documentation/networking/dsa/dsa.rst?

(I'm not as familiar with DSA/switchdev/switch chips as
 with IP/IGMP/MLD/RFC4541 on layer 2+. So especially feedback
 from people more familiar with these lower layes would be
 appreciated.)

-----

Why I'm also wondering if a guideline might be useful because:

Saw this merging of multicast routers ports and MDB approach
discussion here:

https://lore.kernel.org/netdev/db38eb8f-9109-b142-6ef4-91df1c1c9de3@3e8.eu/

I have some suspicion what it might try to achieve, but am unsure
if that can work reliably in all scenarios.
Is this intended as a hack where the switch chip or DSA has no
support to configure multicast router ports?

If yes, what would happen if there is:

1) a layer 3 multicast router
2) a multicast sender with a routable destination address
3) no local multicast listener for 3), so no local reports
   for it?

Would neither an MDB nor a multicast router port be configured then?

Or with two multicast snooping switches, if one of them never sees
the according IGMP/MLD reports due to RFC4541 forwarding
restrictions?

Regards, Linus

Powered by blists - more mailing lists