Hi Nikolai, On Tue, Apr 02, 2024 at 12:28:38PM +0300, Nikolay Aleksandrov wrote: > For the bridge patches: > Nacked-by: Nikolay Aleksandrov <razor@xxxxxxxxxxxxx> > > You cannot break the multicast flood flag to add support for a custom > use-case. This is unacceptable. The current bridge behaviour is correct > your patch 02 doesn't fix anything, you should configure the bridge > properly to avoid all those problems, not break protocols. > > Your special use case can easily be solved by a user-space helper or > eBPF and nftables. You can set the mcast flood flag and bypass the > bridge for these packets. I basically said the same in 2021, if this is > going to be in the bridge it should be hidden behind an option that is > default off. But in my opinion adding an option to solve such special > cases is undesirable, they can be easily solved with what's currently > available. I appreciate your time is limited, but could you please translate your suggestion, and detail your proposed alternative a bit, for those of us who are not very familiar with IP multicast snooping? Bypass the bridge for which packets? General IGMP/MLD queries? Wouldn't that break snooping? And then do what with the packets, forward them in another software layer than the bridge? I also don't quite understand the suggestion of turning on mcast flooding: isn't Joseph saying that he wants it off for the unregistered multicast data traffic?
