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@xxxxxxxxxxxxx> 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 > >
