Messages in this thread | | | From | Ujjal Roy <> | Date | Mon, 20 Mar 2023 22:55:17 +0530 | Subject | Re: Multicast: handling of STA disconnect |
| |
Hi Nik,
Flushing MDB can only be done when we are managing it per station not per port. For that we need to have MCAST_TO_UCAST, EHT and FAST_LEAVE.
Here one more point is - some vendors may offload MCAST_TO_UCAST conversion in their own FW to reduce CPU.
So, the best way is to have MCAST_TO_UCAST enabled and MDB will become per station, so we can delete MDB on disconnect. Shall, I create one patch for review?
Thanks, UjjaL Roy
On Mon, Mar 20, 2023 at 5:38 PM Nikolay Aleksandrov <razor@blackwall.org> wrote: > > On 20/03/2023 13:45, Ujjal Roy wrote: > > Hi Nikolay, > > > > I have some query on multicast. When streams running on an STA and STA > > disconnected due to some reason. So, until the MDB is timed out the > > stream will be forwarded to the port and in turn to the driver and > > dropps there as no such STA. > > > > So, is the multicast_eht handling this scenario to take any action > > immediately? If not, can we do this to take quick action to reduce > > overhead of memory and driver? > > > > I have an idea on this. Can we mark this port group (MDB entry) as > > INACTIVE from the WiFi disconnect event and skip forwarding the stream > > to this port in br_multicast_flood by applying the check? I can share > > the patch on this. > > > > Thanks, > > UjjaL Roy > > Hi, > Fast leave and EHT (as that's v3's fast leave version) are about quickly converging when > a leave is received (e.g. when there are no listeners to quickly remove the mdb). They > don't deal with interface states (IIUC). Why don't you just flush the port's mdb entries > on disconnect? That would stop fwding. > > Cheers, > Nik > >
| |