From mboxrd@z Thu Jan 1 00:00:00 1970 From: Egil Hjelmeland Subject: Re: [PATCH v3 net-next 0/5] IGMP snooping for local traffic Date: Wed, 8 Nov 2017 16:11:12 +0100 Message-ID: <7235b67a-f248-62fe-d5e2-2fa88bcab171@egil-hjelmeland.no> References: <1510010818-23223-1-git-send-email-andrew@lunn.ch> <12851f2e-f6da-db6f-300d-4484c112e6d5@egil-hjelmeland.no> <20171107175849.GB15028@lunn.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Miller , netdev , Florian Fainelli To: Andrew Lunn , Vivien Didelot Return-path: Received: from aibo.runbox.com ([91.220.196.211]:54074 "EHLO aibo.runbox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752687AbdKHPMp (ORCPT ); Wed, 8 Nov 2017 10:12:45 -0500 In-Reply-To: <20171107175849.GB15028@lunn.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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