On 07. nov. 2017 18:58, Andrew Lunn wrote:
Hi Andrew!
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.
To be precise: it is (1 .port_mdb_prepare + 2 x .port_mdb_add), two times.
I see that the outer repeat is due to netdev_for_each_lower_dev() in
br_mdb_switchdev_host(). So that means we get one notification for each
dsa-port which is joined to the bridge.
But _all_ .port_mdb_add are repeated twice as well. This is more
interesting. I suspect that there is a missing "return 0;" in
dsa_switch_mdb_add(), at the end of the "if
(switchdev_trans_ph_prepare(trans)) {". Dating back to
a1a6b7ea7f2de270a51360cc48e7c49f7a283dda.
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.
I waited 10 minutes after stopping the application, still no cleanup.
That was the case when restarted the networking while the application
was running.
But when stopping the application having not restarted the networking,
the .port_mdb_del happen within few seconds.
Cheers
Egil
