o be overlooked.
(I'm not testing using vifs on multiple channels. But even if I was,
I'm not sure if normal operation of wpa_supplicant or hostapd would
be enough to trigger these problems.)
-Tim Shepard
s...@alum.mit.edu
_
sed queue handling can be dealt with by
> stopping/starting relevant queues on channel context changes.
But I don't see how to handle the case here where packets get passed
to the driver with ath_tx_start() and wind up in the scenario above.
slowest processors are fast enough to avoid starvation.
If there's no aggregation, a limit of some sort is needed (probably to
prevent malfunction of the hardware/driver, but in any case to limit
excess latency). And this limit will depend on processor speed (and
will need to be autotuned at runtime).
anding this.
Tomorrow (after I get some sleep) I'm planning on taking a look at
what ath9k looks like with this patch of yours applied and see if that
makes it any easier to figure out what to do about the above bug(s) in
my original patch.
-Tim Shepard
renaming txq in ath9k first) or produce
a new patch that is more like Toke's reworking of my patch.
Hmm...
-Tim Shepard
s...@alum.mit.edu
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://l
a "txq". (I had called the
ieee80211 txq a "txq" and I renamed the ath9k hardware queue "hwq"
throught all the ath9k driver code.This also made ath9k's names of
things more similar to mt76 which I was looking at as an example of a
driver that uses your
getting useful stuff from the chanctx stuff).
Again, thanks for looking at this patch.
I'm now working on figuring out the right way to fix my bug in
the <= v2 patch where I fail to respect the hwq_max_pending
values on the new transmit path, and I plan to post a v3 patch
when I get that
ixes
the problem of not making use of hwq_max_pending() ) might be useful
intermediate steps (that work, and provide improvements) then we can
clean up ath9k removing mechanisms that are no longer needed (breaking
the old transmit path, and somehow handling the chanc
ich wouldn't touch Michal's fq and codel tweaks to
mac80211's new intermediate queues.) But it is useful and there are
some benefits to it (especially with Michal's IFF_NO_QUEUE) even
without the fq and codel stuff.
-Tim Shepard
s...@
