On Fri, 2015-01-23 at 10:56 +0100, Johannes Berg wrote:
> On Thu, 2015-01-22 at 23:30 +0200, Emmanuel Grumbach wrote:
> > When mac80211 disconnects, it drops all the packets on the
> > queues. This happens after the net stack has been notified
> > that we have no link anymore (netif_carrier_off).
> > netif_carrier_off ensures that no new packets are sent to
> > xmit() callback, but we might have older packets in the
> > middle of the Tx path. These packets will land in the
> > driver's queues after the latter have been flushed.
> > Synchronize_net() between netif_carrier_off and drv_flush()
> > will fix this.
> >
> > Note that we can't call synchronize_net inside
> > ieee80211_flush_queues since there are flows that call
> > ieee80211_flush_queues and don't need synchronize_net()
> > which is an expensive operation.
>
> I'm -- with a heavy heart -- applying this for now. TI/wizery spent a
> lot of time optimising the time it takes to roam, and this single line
> will introduce a potential for hundreds of ms of latency into the
> roaming flow.
>
> You (we) really need to think about how to avoid that.
I don't think it will introduce that much of latency.
Note that there is a call to flush() right after that, this means that
any driver which implements this call needs to wait there. So you have
the latency in either place. The only additional latency it adds is for
other RCU sections / packets on other interfaces.
Also - since we just stopped the netif, there can possibly be only one
packet for each vif / ac processing. This is not too much data to
process.
Your call, but to honest, I have been optimizing the roaming as well (as
you know). And it was really bad for drivers that implements the flush()
callback. Especially in cases where you are already far from the AP you
want to roam from. This is why I added the drop parameter and other
optimizations (don't flush() after probing etc...)
Again - your call.
��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
