On 20/03/2023 19:25, Ujjal Roy wrote: > 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 >> >> Hi, Alright, let's see the patch to better understand what is necessary. Also please don't top post on netdev@. Cheers, Nik
