On 6/20/20 4:35 PM, Andrew Lunn wrote: >> So yes, we can read the code here, but I'm wondering which packet types >> would then get this flag set, and which won't. Because in case of >> IGMP/MLD, the packets are in fact forwarded, but the meaning of the flag >> in skb is to prevent the skb from being forwarded further, which seems >> wrong in all cases. >> >> I'm thinking maybe the flag should never be set? > > It is a while since i did much with multicast, so please correct me > when i'm wrong... > > IGMP can use different group addresses as far as i remember. > Join/leave uses the group address of interest. But query can use > 224.0.0.1 or the group address. > > The bridge should learn from joins, either spontaneous or as a reply > to a query. When it sees a join, it should add a multicast FDB to the > hardware for the group, so traffic is forwarded out that port.
Yes, except it's the MDB in this case. But the bridge must also forward the IGMP queries and reports to other ports, otherwise a cascaded multicast router won't see the membership reports and hence won't send frames to our switch. > So for real multicast traffic, we do want the flag set, the hardware > should be doing the forwarding. If we don't set the flag, we end up > with duplication when the SW bridge also forwards the multicast > traffic. Yes, agreed. > For IGMP/MLD itself, we probably need to see what the switch does. For > IGMP using the group address, does the multicast FDB rule match and > cause the hardware to forward the IGMP? No, because snooping is enabled on all ports of the switch by the driver, all IGMP frames are redirected to the CPU port and not egressed on any other port, regardless of the entries in the ATU. > If yes, then we need the flag > set, otherwise the IGMP gets duplicated. If no, then we don't want the > flag set, and leave the SW bridge to do the forwarding, Exactly. > or reply > itself if it is the querier. If it has memberships itself. > 6352 uses the EDSA tagger. But the same bits exist in the DSA tag, > which the 6390 uses, due to incompatibility reasons. So it would be > nice to extend both taggers. But the tag format seems to be a bit different on EDSA from what you described in your other mail. In my datasheet, the code bits are spread across octet 2 and 3. I'll send a patch for EDSA that works for me and solves the problem I had, and then leave it to someone with access to the datasheets of variants implementing the DSA tagging to replicate and test that. Thanks for your help! Daniel
