Date: Tue, 1 Sep 2015 12:33:53 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: Andriy Voskoboinyk <s3erios@gmail.com>, Lawrence Stewart <lstewart@freebsd.org>, "net@freebsd.org" <net@freebsd.org> Subject: Re: mbufq-less iwn(4) Message-ID: <CAJ-Vmokn91fHQyg-AGqCgccRoMS89TuWpQ9RuxL%2B9nmgt%2BX2kQ@mail.gmail.com> In-Reply-To: <20150901112043.GB1023@glebius.int.ru> References: <20150901112043.GB1023@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
hi, We have to do mbuf queues in drivers for wifi, because of 11n aggregation. So on one hand we want to have if_transmit() apply backpressure through the stack, but there's also going to be some buffering. :P I'd like to see that for ic_transmit(). Other thing - ic_transmit() also needs to handle fragments, like I do with ath. Ie, handing it a list of packets is actually a list of 802.11 fragments, rather than separate MPDUs. Another thing - we're modifying the mbufs (adding 802.11 data to it) before we pass them to the driver, and if the driver fails to transmit, we can't just pass it back up the net80211 stack to the tcp or udp layer.. -adrian On 1 September 2015 at 04:20, Gleb Smirnoff <glebius@freebsd.org> wrote: > Hi, Adrian and Andriy! > > One of the fundamental things that me and Lawrence want to bring to > FreeBSD 12 (probably won't be in time with 11), is the NIC TX exhaustion > notification to the stack, also named as "network stack backpressure". > > The problem is that when NICs TX queue is full we start to lose packets, > just as if they were lost somewhere in a wire, outside of our control. > Of course TCP engine copes with that and does necessary retransmitting. > > The idea is that we can make TCP perform much better, is we report the > TX problem to it via ENOBUFS and DO NOT free the mbuf, since protocol > may have better idea on its destiny. > > In the projects/ifnet branch, I already put this idea into the code. > In the branch drivers if_transmit doesn't free. I also put this idea > into the recent net80211 changes. New ic_transmit doesn't free. However, > due to most drivers have software queues as historical artifact, this > new semantic of ic_transmit is degenerated. > > So, the long term plan is to slowly get rid of software mbuf queues > in drivers. The protocols should care about queueing (for example > ARP already does :)). We probably won't be able to get rid of software > queues everywhere before Lawrence does the needed work to TCP, since > now software queues are smoothing transmission for drivers that have > very small hardware queues. > > Speaking particularly about iwn(4). Looks like the hardware has > enough descriptors to run w/o software queue. Right now writing > this email through WiFi connection with patched driver. Didn't > notice any issues with download/upload speed. > > Any objections on checking it in? > > -- > Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokn91fHQyg-AGqCgccRoMS89TuWpQ9RuxL%2B9nmgt%2BX2kQ>