request for help: 'fixing' the 802.11 TX path

[Adrian Chadd]

On 28 October 2012 20:43, PseudoCylon <moonlightakkiy at yahoo.ca> wrote:

> Cannot we just add custom hand off function to ieee80211_start()?

Yes. That's the general idea. But what I don't want to do is have it
just wake up the driver TX taskqueue - well, unless we have to.

That means we'll have two context switches for each frame being
transmitted and that as a concept just sucks.

See my (very recent) email to -wireless - I broke TCP throughput quite
substantially by moving ath(4) TX into the taskqueue. I thought the
problem was _just_ going to be how overlapping, direct dispatch TX
could be preempted by the RX tasklet and TX completion, but there's
obviously more going on.

I'm going to experiment some more with it before I go down this path.

I don't want to do the linux thing of "just grab a txrx spinlock in
mac80211 before calling the driver", serialising everything that way.
That feels plain ugly. But then, a lot of our network drivers do much
the same thing - they grab big, long-held locks and they either
implement their own lockless queue in front of that lock (eg, what the
intel/chelsio code does) or they just ignore it entirely and leave it
up to the scheduler to wake up threads once the contending lock is
unlocked.

I have all kinds of concerns about the behaviour of if_bridge and
other if_transmit() enabled friends when sending to one of these badly
locked drivers, however that's going to have to wait. Well, maybe I'll
poke the network people at meetbsd this weekend and see what they
think.



Adrian