From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-ewr.dyndns.com (mxout-029-ewr.mailhop.org [216.146.33.29]) by lists.bufferbloat.net (Postfix) with ESMTP id 106D82E0273 for ; Thu, 17 Feb 2011 00:31:18 -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 4BF5D92C60B for ; Thu, 17 Feb 2011 08:31:18 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 78.46.109.217 Received: from sipsolutions.net (he.sipsolutions.net [78.46.109.217]) by mail-11-ewr.dyndns.com (Postfix) with ESMTP id 3732C92C232 for ; Thu, 17 Feb 2011 08:31:14 +0000 (UTC) Received: by sipsolutions.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1PpzGY-0003rk-V1; Thu, 17 Feb 2011 09:31:11 +0100 Subject: Re: [RFC] mac80211: implement eBDP algorithm to fight bufferbloat From: Johannes Berg To: "John W. Linville" In-Reply-To: <1297907356-3214-1-git-send-email-linville@tuxdriver.com> References: <1297619803-2832-1-git-send-email-njs@pobox.com> <1297907356-3214-1-git-send-email-linville@tuxdriver.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 Feb 2011 09:31:09 +0100 Message-ID: <1297931469.3750.9.camel@jlt3.sipsolutions.net> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 17 Feb 2011 01:28:56 -0800 Cc: bloat-devel@lists.bufferbloat.net, linux-wireless@vger.kernel.org, "Nathaniel J. Smith" 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: Thu, 17 Feb 2011 08:31:19 -0000 On Wed, 2011-02-16 at 20:49 -0500, John W. Linville wrote: > @@ -212,6 +216,11 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb) > if (memcmp(hdr->addr2, sta->sdata->vif.addr, ETH_ALEN)) > continue; > > + atomic_dec(&sta->sdata->enqueued); Note that TX status isn't reliable under any circumstances. Many drivers will reliably return the SKB if it was enqueued correctly to the device, but that may already fail (failure to allocate URBs, DMA memory etc.) In this case, the counter will continually be too high, leading the code below to drop many more packets than necessary. This is what I was referring to earlier :-) > @@ -1323,6 +1325,20 @@ static int __ieee80211_tx(struct ieee80211_local *local, > > sdata = vif_to_sdata(info->control.vif); > > + /* test for queue admission qualifications */ > + tserv_ns_avg = ewma_read(&sdata->tserv_ns_avg); > + /* constants 2 msec and offset 5 should be tunable? */ > + max_enqueued = 2 * NSEC_PER_MSEC / tserv_ns_avg + 5; > + if (atomic_read(&sdata->enqueued) > max_enqueued) { > + /* silently drop */ > + dev_kfree_skb(skb); > + return IEEE80211_TX_OK; > + } As Nathaniel pointed out, this should instead stop the queue to give normal QoS mechanisms a chance (this one packet can be kept for later, or transmitted anyway, or the code to test all this can be after the packet is sent). However, since "sdata->enqueued" will drift as explained above, this isn't feasible anyhow. > + /* timestamp queue entry and increment queue length */ > + skb->tstamp = ktime_get(); > + atomic_inc(&sdata->enqueued); Additionally, this assumes that tx() cannot fail -- it can until my void patch. Sorry, this approach just won't work because we don't have perfect skb accounting across the stack. johannes