From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BC5BD3B2A4 for ; Mon, 25 Jun 2018 06:38:25 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1529923102; bh=0YMZcJbgEurHY38IgVTJd4mtxeilz2CKLd7/qudg7Co=; h=From:To:Subject:In-Reply-To:References:Date:From; b=jdGdusj3FCQVekDtdaIjvwvuwv6IgEJHsOkRPKTDM38thSCeoI+A/tFpTII+2mJzx mpkbfO6h2hplJAheets/093Xr1SZmlKNliZduE4HsJn/tXSFK0V+B6/FWzA/by+Vcj nAtmsa9/tGT6U/zQ64guQNxV2Rdk//DD7PKbs9s2XGKBg8/RdMe4bGO8ScnFBsto8S g14NM16MJLn4zewTpxrJtqys+4aWpw6+5Bz698uP/i6l7976KkZFYwjOLYDre3wh7o SbBK3WafwofVoe42g3Yezdua78FZMpQKIU7LJIMFae55Zxj4KMNBIqqu6+YVVZVDSh sketCWAquVKeg== To: Michael Richardson , bloat In-Reply-To: <18224.1529704505@localhost> References: <8736xgsdcp.fsf@toke.dk> <838b212e-7a8c-6139-1306-9e60bfda926b@gmail.com> <8f80b36b-ef81-eadc-6218-350132f4d56a@pollere.com> <9dbb8dc8-bec6-8252-c063-ff0ba5fd7c1a@pollere.com> <25305.1529678986@localhost> <47EC21F5-94D2-4982-B0BE-FA1FA30E7C88@gmail.com> <18224.1529704505@localhost> Date: Mon, 25 Jun 2018 12:38:24 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87muvjnobj.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 10:38:25 -0000 Michael Richardson writes: > Jonathan Morton wrote: > >>> I would instead frame the problem as "how can we get hardware to > >>> incorporate extra packets, which arrive between the request and grant > >>> phases of the MAC, into the same TXOP?" Then we no longer need to > >>> think probabilistically, or induce unnecessary delay in the case that > >>> no further packets arrive. > >> > >> I've never looked at the ring/buffer/descriptor structure of the ath9k, but > >> with most ethernet devices, they would just continue reading descriptors > >> until it was empty. Is there some reason that something similar can not > >> occur? > >> > >> Or is the problem at a higher level? > >> Or is that we don't want to enqueue packets so early, because it's a source > >> of bloat? > > > The question is of when the aggregate frame is constructed and > > "frozen", using only the packets in the queue at that instant. When > > the MAC grant occurs, transmission must begin immediately, so most > > hardware prepares the frame in advance of that moment - but how far in > > advance? > > Oh, I understand now. The aggregate frame has to be constructed, and it's > this frame that is actually in the xmit queue. I'm guessing that it's in the > hardware, because if it was in the driver, then we could perhaps do > something? No, it's in the driver for ath9k. So it would be possible to delay it slightly to try to build a larger one. The timing constraints are too tight to do it reactively when the request is granted, though; so delaying would result in idleness if there are no other flows to queue before then... Even for devices that build aggregates in firmware or hardware (as all AC chipsets do), it might be possible to throttle the queues at higher levels to try to get better batching. It's just not obvious that there's an algorithm that can do this in a way that will "do no harm" for other types of traffic, for instance... -Toke