Re: [PATCH 1/4] mwl8k: Do not stop tx queues

[Nishant Sarmukadam <nishants@marvell.com>]

On Tue, 2011-04-19 at 00:48 -0700, Lennert Buytenhek wrote:
> On Tue, Apr 19, 2011 at 11:12:49AM +0530, Nishant Sarmukadam wrote:
> 
> > From: Pradeep Nemavat <pnemavat@marvell.com>
> > 
> > This is in preparation to support life time expiry of packets in the
> > hardware to avoid head-of-line blocking where a slow client can
> > hog a tx queue and affect the traffic to a faster client from the same
> > queue. Time stamp the packets in driver to allow dropping them in the
> > hardware if they are queued for more than 500ms.
> > 
> > Since queues are not being stopped now, we need to be prepared for
> > a situation where packets hit the driver after the queues are full.
> > Drop all such packets in the driver itself.
> 
> What this patch seems to do is: don't propagate queue start/stop
> indications to mac80211, and if a packet is handed to mwl8k for
> transmission while a TX queue is full, just drop it in the driver.
> (This doesn't seem to correspond with the commit message.)

We were invoking mac80211 routines to start/stop tx queues. Since we do
not call these routines now, the queues will not be stopped anymore.
Hence, packets that enter the driver after the corresponding queue is
full, need to be dropped. This is mentioned in the commit description.
Please let me know if I am missing something. 

> 
> But since the driver still has an accurate idea of TX queue fullness
> (i.e. it's not as if at transmit time, you go and transparently reclaim
> TX queue entries), why do you need to start/stop mac80211 TX queues at
> all?  Won't it still work fine without deleting that logic?

We need to timestamp all tx packets. If we stop the queues, packets will
be queued up outside the driver (in queue full conditions). Since we
will be able to timestamp the packets only after they hit the driver,
the timestamp will be less accurate since we cannot consider the time
the packets spent in the queues outside the driver. Such packets add up
to the overall latency considerably. Hence we are not stopping the
queues anymore.