On Sat, Apr 03, 2021 at 04:46:06PM +0300, Vladimir Oltean wrote: > On Sat, Apr 03, 2021 at 03:26:36PM +0200, Oleksij Rempel wrote: > > On Sat, Apr 03, 2021 at 04:03:18PM +0300, Vladimir Oltean wrote: > > > Hi Oleksij, > > > > > > On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote: > > > > The ar9331 switch is not forwarding IGMP and MLD packets if IGMP > > > > snooping is enabled. This patch is trying to mimic the HW heuristic to take > > > > same decisions as this switch would do to be able to tell the linux > > > > bridge if some packet was prabably forwarded or not. > > > > > > > > Signed-off-by: Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> > > > > --- > > > > > > I am not familiar with IGMP/MLD, therefore I don't really understand > > > what problem you are trying to solve. > > > > > > Your switch has packet traps for IGMP and MLD, ok. So it doesn't forward > > > them. Must the IGMP/MLD packets be forwarded by an IGMP/MLD snooping > > > bridge? Which ones and under what circumstances? > > > > I'll better refer to the rfc: > > https://tools.ietf.org/html/rfc4541 > > Ok, the question might have been a little bit dumb. > I found this PDF: > https://www.alliedtelesis.com/sites/default/files/documents/how-alliedware/howto_config_igmp1.pdf > and it explains that: > - a snooper floods the Membership Query messages from the network's > querier towards all ports that are not blocked by STP > - a snooper forwards all Membership Report messages from a client > towards the All Groups port (which is how it reaches the querier). > > I'm asking this because I just want to understand what the bridge code > does. Does the code path for IGMP_HOST_MEMBERSHIP_REPORT (for example) > for a snooper go through should_deliver -> nbp_switchdev_allowed_egress, > which is what you are affecting here? yes. the exact path should depend on this configuration option: /sys/devices/virtual/net/test/bridge/multicast_snooping I assume, some optimization can be done by letting DSA know the state of multicast_snooping. Off-topic question, this patch set stops to work after rebasing against latest netdev. I get following warning: ip l s lan0 master test RTNETLINK answers: Invalid argumen Are there some API changes? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
