From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 52377201A76 for ; Wed, 11 May 2011 02:46:09 -0700 (PDT) Received: by wyb32 with SMTP id 32so324651wyb.16 for ; Wed, 11 May 2011 02:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=DwfYR36DjEdhjJ6Gb3LOmeN8CP1TCIvnomwOua9S2/M=; b=GLlX6nRlYoibOZ/FZij5spYfRNxFTHCYLoRzF8UaLnlKLPp3xEOzyEWT2Hpo03T8Mw e4Ojhk/wg4ReAktcjG2ZcA3672U1nyobr2seUqn05Bmt9uAc03A2+/+iuy9fqYr8QIbU E5UQigO1IOxjS435y8zq4OlMP7k1tOHGi+3Zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=tfKspM2pNgJLqDHH0gPXajHKlY0FZ2sqLAu1Jv4pyoAHpZ17hh5QRwkNS8ilMX6J9U 740eNaD2lWKq18slVjj6Hi5n4EkdUpaQymCfhJfvzDIIyUMYyq+ZIyaho5BLYz03Y18O 83HMHcsEg766e+naJZTI1tYUGFhZ+n3Ju8E1c= Received: by 10.216.63.130 with SMTP id a2mr256361wed.61.1305107601322; Wed, 11 May 2011 02:53:21 -0700 (PDT) Received: from [10.150.51.213] (gw0.net.jmsp.net [212.23.165.14]) by mx.google.com with ESMTPS id b20sm4917139wbb.33.2011.05.11.02.53.18 (version=SSLv3 cipher=OTHER); Wed, 11 May 2011 02:53:19 -0700 (PDT) From: Eric Dumazet To: Richard Scheffenegger In-Reply-To: <3AE3B8A6A3EC4423A3BB4F1D6596B848@srichardlxp2> References: <4DB70FDA.6000507@mti-systems.com> <4DC2C9D2.8040703@freedesktop.org><20110505091046.3c73e067@nehalam> <6E25D2CF-D0F0-4C41-BABC-4AB0C00862A6@pnsol.com> <35D8AC71C7BF46E29CC3118AACD97FA6@srichardlxp2> <1304964368.8149.202.camel@tardy> <3AE3B8A6A3EC4423A3BB4F1D6596B848@srichardlxp2> Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 May 2011 11:53:16 +0200 Message-ID: <1305107596.4341.6.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: Stephen Hemminger , bloat@lists.bufferbloat.net Subject: Re: [Bloat] Burst Loss 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: Wed, 11 May 2011 09:46:10 -0000 Le mercredi 11 mai 2011 à 10:53 +0200, Richard Scheffenegger a écrit : > Well, the transmit descriptors (header + pointer to the data to be > segmented) is in the hand of the hw driver... > The hw driver could at least check if the current list of transmit > descriptors is for different tcp sessions > (or interspaced non-tcp traffic), and could interleave these descriptors > (reorder them, before they are processed > by hardware - while obviously maintaining relative ordering between the > descriptors belonging to the same flow. > > Also, I think this feature could be utilized for pacing to some extent - > interspace the (valid) traffic descriptors > with descriptors that will cause "invalid" packets to be sent (ie. dst mac > == src max; should be dropped by the first switch). It's been well known > that properly paced traffic is much more resilient than traffic being sent > in short bursts of wirespeed trains of packets. (TSO defeats the > self-clocking of TCP with ACKs). In French, we would say "Avoir le beurre et l'argent du beurre" ;) GSO is for high performance data xmits, usually in LAN. Dont expect NICS perform the hard/smart work for you. Of course hardware vendors claim they can do this, but this is mostly done with vendor specific methods, and you might spend a lot of time tuning hardware. If you want AQM, better use a well chosen qdisc setup (depending on the workload), and disable TSO/GSO. This will work well with all hardware, and presumably last for longer times (including hardware changes)