diff options
author | adrian <adrian@FreeBSD.org> | 2013-02-13 05:32:19 +0000 |
---|---|---|
committer | adrian <adrian@FreeBSD.org> | 2013-02-13 05:32:19 +0000 |
commit | af7893e0d41c28bee0d520d4e21900ace59ed963 (patch) | |
tree | 42ad376dd393e5ee24ee4cd2775f4de71f6b5d53 /share | |
parent | 5d56fc6ccd907da03c2ffd167a384b205ca05f75 (diff) | |
download | FreeBSD-src-af7893e0d41c28bee0d520d4e21900ace59ed963.zip FreeBSD-src-af7893e0d41c28bee0d520d4e21900ace59ed963.tar.gz |
Pull out the if_transmit() work and revert back to ath_start().
My changed had some rather significant behavioural changes to throughput.
The two issues I noticed:
* With if_start and the ifnet mbuf queue, any temporary latency
would get eaten up by some mbufs being queued. With ath_transmit()
queuing things to ath_buf's, I'd only get 512 TX buffers before I
couldn't queue any further frames.
* There's also some non-zero latency involved with TX being pushed
into a taskqueue via direct dispatch. Any time the scheduler didn't
immediately schedule the ath TX task would cause extra latency.
Various 1ge/10ge drivers implement both direct dispatch (if the TX
lock can be acquired) and deferred task transmission (if the TX lock
can't be acquired), with frames being pushed into a drbd queue.
I'll have to do this at some point, but until I figure out how to
deal with 802.11 fragments, I'll have to wait a while longer.
So what I saw:
* lots of extra latency, specially under load - if the taskqueue
wasn't immediately scheduled, things went pear shaped;
* any extra latency would result in TX ath_buf's taking their sweet time
being replenished, so any further calls to ath_transmit() would drop
mbufs.
* .. yes, there's no explicit backpressure here - things are just dropped.
Eek.
With this, the general performance has gone up, but those subtle if_start()
related race conditions are back. For some reason, this is doubly-obvious
with the AR5416 NIC and I don't quite understand why yet.
There's an unrelated issue with AR5416 performance in STA mode (it's
fine in AP mode when bridging frames, weirdly..) that requires a little
further investigation. Specifically - it works fine on a Lenovo T40
(single core CPU) running a March 2012 9-STABLE kernel, but a Lenovo T60
(dual core) running an early November 2012 kernel behaves very poorly.
The same hardware with an AR9160 or AR9280 behaves perfectly.
Diffstat (limited to 'share')
0 files changed, 0 insertions, 0 deletions