request for help: 'fixing' the 802.11 TX path

[Andre Oppermann]

On 29.10.2012 04:53, Adrian Chadd wrote:
> 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 can't believe that TCP is getting broken by just introducing some
additional delay in the TX path.  That can't add more than 300ms,
can it?  There must be something else going on.  Most likely either
severe packet loss (the m_nextpkt leak you mentioned earlier) or
severe packet re-ordering.

So don't rule out the TX taskqueue concept quite yet.

-- 
Andre