From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-ewr.dyndns.com (mxout-120-ewr.mailhop.org [216.146.33.120]) by lists.bufferbloat.net (Postfix) with ESMTP id 4FE372E0050 for ; Mon, 21 Feb 2011 11:30:44 -0800 (PST) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-11-ewr.dyndns.com (Postfix) with ESMTP id 95C3192BC77 for ; Mon, 21 Feb 2011 19:30:43 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 70.61.120.58 Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by mail-11-ewr.dyndns.com (Postfix) with ESMTP id 4DF7892BC35 for ; Mon, 21 Feb 2011 19:30:43 +0000 (UTC) Received: from uucp by smtp.tuxdriver.com with local-rmail (Exim 4.63) (envelope-from ) id 1PrbSq-0006qG-FP; Mon, 21 Feb 2011 14:30:32 -0500 Received: from linville-8530p.local (localhost.localdomain [127.0.0.1]) by linville-8530p.local (8.14.4/8.14.4) with ESMTP id p1LJFBkZ014185; Mon, 21 Feb 2011 14:15:11 -0500 Received: (from linville@localhost) by linville-8530p.local (8.14.4/8.14.4/Submit) id p1LJFAQN014184; Mon, 21 Feb 2011 14:15:10 -0500 Date: Mon, 21 Feb 2011 14:15:10 -0500 From: "John W. Linville" To: Jim Gettys Subject: Re: [RFC v2] mac80211: implement eBDP algorithm to fight bufferbloat Message-ID: <20110221191510.GG9650@tuxdriver.com> References: <1297907356-3214-1-git-send-email-linville@tuxdriver.com> <1298064074-8108-1-git-send-email-linville@tuxdriver.com> <1298302086.3707.13.camel@jlt3.sipsolutions.net> <4D628EDE.1010102@freedesktop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D628EDE.1010102@freedesktop.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dan Williams , Javier Cardona , bloat-devel@lists.bufferbloat.net, Dave Woodhouse X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:30:44 -0000 On Mon, Feb 21, 2011 at 11:12:14AM -0500, Jim Gettys wrote: > On 02/21/2011 10:28 AM, Johannes Berg wrote: > >However, Nathaniel is right -- if the skb is freed right away during > >tx() you kinda estimate its queue time to be virtually zero. That > >doesn't make a lot of sense and might in certain conditions exacerbate > >the problem, for example if the system is out of memory more packets > >might be allowed through than in normal operation etc. For those only reading the bloat lists, I replied elsewhere to clarify that the present patch is only calculating max_enqueued for frames that result in a tx status report (i.e. not for dropped frames) -- just in case that detail is somehow relevant... > >Also, for some USB drivers I believe SKB lifetime has no relation to > >queue size at all because the data is just shuffled into an URB. I'm not > >sure we can solve this generically. I'm not really sure how this works > >for USB drivers, I think they queue up frames with the HCI controller > >rather than directly with the device. > > Let me give a concrete example: > > I checked with Javier Cardona about the Marvell module (libertas > driver) used on OLPC a couple months ago. > > It turns out there are 4 packets of buffering out in the wireless > module itself (clearly needed for autonomous forwarding). > > There is also one packet buffer in the device driver itself; Dave > Woodhouse says it simplified the driver greatly. > > I don't know if anyone has been thinking about how to manage the > buffering from top to bottom, with devices that may do internal > buffering in various places. (FWIW, my current patch won't affect the libertas driver...) The role I see my patch playing is to evaluate how good a job the driver/device is doing with it's own buffers. If it is keeping its latency low, then I will allow it more fragments to buffer. If its latency grows too large, I throttle the number of fragments I allow the driver to see. To a large degree, it doesn't matter how much buffering the driver/device is doing so long as it is moving the frames along quickly. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready.