> Hi Andrew! > > I tested this series today on my board with lan9303, and it does seem to > work. But no extensive testing though.
Cool, thanks. I've only been able to test on Marvell hardware. > Some observations, not meant to delay the series: > > When local application join multicast; the driver get 2 X .port_mdb_prepare > + 4 x .port_mdb_add for the address. Humm, i would expect equal numbers of those. > "bridge mdb" does not list local multicast memberships, is that a "feature"? Yes. The br0 interface is not really a port of the bridge. It is special. And hence many of the bridge commands don't list it. > While I had an application joined on a multicast address; I restarted the > networking: meaning deleting the bridge and setting it up again. No > .port_mdb_del on the multicast address. Stopped the application. Still no > .port_mdb_del on the multicast address. So the multicast address stays in > the HW fdb, until I started and stopped the application again. Not really a > problem, just an observation. The bridge is working by snooping joins/leaves. When the application joined the group, the kernel would of sent an IGMP report. This triggers the snooping code to request the hardware to start forwarding frames to the hardware. When the application quits, it might send a leave. But it is not required. The bridge however has a timer. The IGMP querier in your network should cause all active groups to send a report every so often. This keeps the timer alive. If the timer expires, the bridge should then delete the group from the hardware. So try stopping your application, and waiting a while. > Then finally, there is a more serious issue related to IGMPv2. As I > suspected, with "IGMP snooping for local traffic", I have to activate "IGMP > trapping" in the lan9303 HW in order to get it to work with a IGMPv2 > querier. For Marvell hardware, it detects all IGMP frames and forwards them to the CPU. It does not matter if they are IGMPv2 or v3. > (Remember, unlike IGMPv3, IGMPv2 reports are "inband" in the > group). The HW allows me to select which ports receive IGMP packets. The > best is to only send to CPU, so the SW bridge can do the right thing in all > situations. However, then we must make sure skb->offload_fwd_mark is zero > for IGMP packets. Which was easy to do in my proof-of-concept test, but I > suspect a proper test on ip->protocol is more complicated? Humm, interesting. Not thought about that. And my testing has been limited to a single switch. I will try to find a setup with multiple switches and see what happens with the Marvell hardware. Thanks Andrew