From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-ewr.dyndns.com (mxout-124-ewr.mailhop.org [216.146.33.124]) by lists.bufferbloat.net (Postfix) with ESMTP id 63B562E0271 for ; Tue, 15 Mar 2011 16:46:09 -0700 (PDT) Received: from scan-01-ewr.mailhop.org (scanner [10.0.141.223]) by mail-04-ewr.dyndns.com (Postfix) with ESMTP id 32ADE7E4ADE for ; Tue, 15 Mar 2011 23:46:08 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-04-ewr.dyndns.com (Postfix) with ESMTP id 07E147E4AAB for ; Tue, 15 Mar 2011 23:46:07 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id 8EA835EAD1 for ; Tue, 15 Mar 2011 17:46:06 -0600 (MDT) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 11E8D12085F; Tue, 15 Mar 2011 17:46:04 -0600 (MDT) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Eric Dumazet Organization: Teklibre - http://www.teklibre.com References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> <1300212877.2087.2155.camel@tardy> <20110315183111.GB2542@tuxdriver.com> <29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com> <20110315205146.GF2542@tuxdriver.com> <219C7840-ED79-49EA-929D-96C5A6200401@gmail.com> <20110315151946.31e86b46@nehalam> <1300228592.2087.2191.camel@tardy> <1300229578.2565.29.camel@edumazet-laptop> Date: Tue, 15 Mar 2011 17:46:04 -0600 In-Reply-To: <1300229578.2565.29.camel@edumazet-laptop> (Eric Dumazet's message of "Tue, 15 Mar 2011 23:52:58 +0100") Message-ID: <87fwqo54n7.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Stephen Hemminger , bloat@lists.bufferbloat.net Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 23:46:09 -0000 Eric Dumazet writes: > Le mardi 15 mars 2011 =C3=A0 15:36 -0700, Rick Jones a =C3=A9crit : >> Back and forth synchronization between driver and device is >> doubleplusungood. Being able to remove a packet on the tx queue already >> made known to the NIC sounds like it could become a rathole. If you are >> lucky, you *might* have a "valid/invalid" bit in a packet descriptor >> that the driver could hope to set before the NIC had pulled-in a copy >> across the I/O bus. > > There are two different use cases : > > 1) Wired devices, where we want to push more 10+ Gbps, so we can assume > a posted skb is transmitted immediately. Even a basic qdisc can be a > performance bottleneck. Set TX ring size to 256 or 1024+ buffers to > avoid taking too many interrupts. To talk to this a bit, the huge dynamic range discrepancy between a 10GigE device and what it may be connected to worries me. Some form of fair queuing should be applied before the data hits the driver. It would be good to know what 10Gbps hw was capable of pushing more smarts (such as nRED) further down into the hardware itself, this may inform future software abstractions and future hardware designs. > > 2) wireless, were typical bandwidth is small enough we can afford a > qdisc with a trafic shaper, good flow classification, whatever limit on > "maximum waiting time in qdisc queue or drop it" and a very small queue > on hardware ? > > In both cases, we dont need to "cancel" a packet post to NIC hardware, > or we need special hardware support (some NICS already provide hardware > TX completion times) Which NICs? For example, a whole bunch of us (at least 7 so far) have settled on the wndr3700 hardware as a good base for experimenting with wireless solutions. Finding out what NICs are smart enough to be managed this way would be a goodness. (And ultimately help them compete better in the marketplace) > > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave Taht http://nex-6.taht.net