Re: [PATCH] ath9k: Implement op_flush()

[Vasanthakumar Thiagarajan <vasanth@atheros.com>]

On Sat, Feb 19, 2011 at 03:26:30PM +0530, Johannes Berg wrote:
> On Sat, 2011-02-19 at 15:19 +0530, Vasanthakumar Thiagarajan wrote:
> > On Sat, Feb 19, 2011 at 02:54:00PM +0530, Johannes Berg wrote:
> > > On Sat, 2011-02-19 at 01:13 -0800, Vasanthakumar Thiagarajan wrote:
> > > > When op_flush() is called with no drop (drop=false), the driver
> > > > tries to tx as many frames as possible in about 100ms on every
> > > > hw queue. During this time period frames from sw queue are also
> > > > scheduled on to respective hw queue.
> > > 
> > > Given how long HW queues currently are, I wouldn't set the timeout to
> > > 100ms -- mac80211 has no expectation how long this will take, although
> > > 100ms seems pretty long I'm not sure it'll always be sufficient?
> > 
> > It is not that we wait for 100ms always, we return as soon as
> > possible if there are no pending frames in sw/hw queues. I never
> > hit this timeout though. In the worst case there can be 128 (4 aggr)
> > frames pending in sw queue and 2 in hw queue. If we assume each one of
> > these aggregates has 4ms duration, we at least need 24ms air time at
> > the lowest rate. If they are not part of AMPDU, it would take a
> > little bit more I think. So, probably we can give ~40ms timeout,
> > is that reasonable?. If i'm reading the code correctly, iwlwifi
> > seems to use 2000ms.
> 
> Ok. I wasn't concerned about it being too high, I was thinking 100ms
> might not be enough, but since you say it will be I guess it's fine.

Yeah, I misread it. This 100ms timeout is on every ac queue and is pretty
much good enough from my testing.

Vasanth