Date: Mon, 29 Oct 2012 10:47:15 +0100 From: Andre Oppermann <oppermann@networx.ch> To: Adrian Chadd <adrian@freebsd.org> Cc: FreeBSD Net <freebsd-net@freebsd.org>, PseudoCylon <moonlightakkiy@yahoo.ca>, freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org Subject: Re: request for help: 'fixing' the 802.11 TX path Message-ID: <508E50A3.1030008@networx.ch> In-Reply-To: <CAJ-Vmok5vJNYUbsUuk_Ps=7oLvpJutuyDZ7279bft1qYiYmeTA@mail.gmail.com> References: <CAFZ_MYL3v%2BhAea5RaBL4i9o_JjN6_u66znmXXcPsh11L7hHYEg@mail.gmail.com> <CAJ-Vmok5vJNYUbsUuk_Ps=7oLvpJutuyDZ7279bft1qYiYmeTA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29.10.2012 04:53, Adrian Chadd wrote: > On 28 October 2012 20:43, PseudoCylon <moonlightakkiy@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?508E50A3.1030008>