From owner-freebsd-net@freebsd.org Tue Sep 1 19:33:54 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B00B9C88D0 for ; Tue, 1 Sep 2015 19:33:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E023761D for ; Tue, 1 Sep 2015 19:33:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DFAC59C88CF; Tue, 1 Sep 2015 19:33:53 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C65549C88CE for ; Tue, 1 Sep 2015 19:33:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 937F461B; Tue, 1 Sep 2015 19:33:53 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbkq10 with SMTP id kq10so9301539igb.0; Tue, 01 Sep 2015 12:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=icz93U7dNDpzHD2lqvklPvfn3sf/Q/mxcgPukggS5Cw=; b=KT497+vWTOnDEMpevCJGpnyFfgRHQPuig92FJ4hzXjobAS/KH+ypKpNfp7hm5CPWio RdV1p8Y2Mcl+m1QfXDgW+bFa05FwPeOBVw+9oKIZlGkO/+AAe4MP5i2zYrl0w0hw1AY3 vVdnXavkDPaBDK6VYRFFTHEMwHO4tnXRTVlfPYEP8VIX/vJDIEoknW6Qr0xCQ3lnCric uz49M9Ep6jpUcgKcHbkw4Fr9M/5Fz+FuOvAe1W/GIfGcnmjBF/Pghxil4GiwvbWo/y8o v53X+2mxhRrUpomhUlhp4hJd/my+MEpiw78Sn8ECo9UXK6dmuv8PP+fcaOGkdii/q0my Cyag== MIME-Version: 1.0 X-Received: by 10.50.73.97 with SMTP id k1mr3842431igv.61.1441136033098; Tue, 01 Sep 2015 12:33:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.28.208 with HTTP; Tue, 1 Sep 2015 12:33:53 -0700 (PDT) In-Reply-To: <20150901112043.GB1023@glebius.int.ru> References: <20150901112043.GB1023@glebius.int.ru> Date: Tue, 1 Sep 2015 12:33:53 -0700 X-Google-Sender-Auth: dP9sBKxjgSLqMMDT2dj0MiPyoKE Message-ID: Subject: Re: mbufq-less iwn(4) From: Adrian Chadd To: Gleb Smirnoff Cc: Andriy Voskoboinyk , Lawrence Stewart , "net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 19:33:54 -0000 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 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.