On Fri, Jan 23, 2015 at 12:33 PM, Johannes Berg
johan...@sipsolutions.net wrote:
On Fri, 2015-01-23 at 10:18 +, Grumbach, Emmanuel wrote:
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
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()
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).
On Fri, 2015-01-23 at 10:18 +, Grumbach, Emmanuel wrote:
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
On Fri, 2015-01-23 at 13:36 +0200, Emmanuel Grumbach wrote:
It's not actually just one packet for each vif/ac - it's a whole tail
of whatever other RCU usages there are. Back when this was discussed,
the wizery people measured this to hundreds of ms in many not too
uncommon cases.
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
