From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qy0-f178.google.com (mail-qy0-f178.google.com [209.85.216.178]) (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 DDF37201745 for ; Fri, 13 May 2011 12:24:19 -0700 (PDT) Received: by qyk2 with SMTP id 2so1971626qyk.16 for ; Fri, 13 May 2011 12:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=geekhold.com; s=google; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SUHgvoR6l1+aTX7Lr3s2SlbXOvMq/YDaktE1WKKOvfg=; b=FrVqh6J+rTJeQp0oJSzmtC/pTEwtMducidOFzSX6c3EYGrofiFOqKhXOjlifFE9tjJ lglZP+g2xfyfsBqvaaOnlBszpowjuFZm8lRrrzDOa8Dah2t7wK+BIK/PbFfVHgjOIdfx jchmKCNo2T/tYRerGVeL6rEcPiYWZOHbXoWJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=geekhold.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=OTv4mPcGz535z5Uq0mtrIniPlkApsVnvheWZn11jHJ9zZX3yIhT6vnRgQilafeZp3l WhSHtONqGwR1uWOe39lhc2laxaoe5Tb2x4sup1T+/3/ZttqPAxs+uc+s1UmqiNqOEkhy Q0G2+Hsv8jUHu/t4/Sm4b1UTpyrmtVleZN8KM= Received: by 10.224.28.201 with SMTP id n9mr1526500qac.28.1305315160199; Fri, 13 May 2011 12:32:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.130 with HTTP; Fri, 13 May 2011 12:32:20 -0700 (PDT) In-Reply-To: <1305297321.8149.549.camel@tardy> 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> <4DD9A464-8845-49AA-ADC4-A0D36D91AAEC@cisco.com> <1305297321.8149.549.camel@tardy> From: Denton Gentry Date: Fri, 13 May 2011 12:32:20 -0700 Message-ID: To: rick.jones2@hp.com, Kevin Gross Content-Type: multipart/alternative; boundary=0015175cdf1871926604a32d5e76 Cc: 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: Fri, 13 May 2011 19:24:20 -0000 --0015175cdf1871926604a32d5e76 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 13, 2011 at 7:35 AM, Rick Jones wrote: > > For a short time, servers with gigabit NICs suffered but smarter NICs > > were developed (TSO, LRO, other TLAs) and OSs upgraded to support them > > and I believe it is no longer a significant issue. > > Are TSO and LRO going to be sufficient at 40 and 100 GbE? Cores aren't > getting any faster. Only more plentiful. NICs seem to be responding by hashing incoming 5-tuples to distribute flows across cores. > And while it isn't the > strongest point in the world, one might even argue that the need to use > TSO/LRO to achieve performance hinders new transport protocol adoption - > the presence of NIC offloads for only TCP (or UDP) leaves a new > transport protocol (perhaps SCTP) at a disadvantage. True, and even UDP seems to be often blocked for anything other than DNS. --0015175cdf1871926604a32d5e76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 13, 2011 at 7:35 AM, Rick Jones <rick.jones2@hp.com>= wrote:
> For a short time, servers with gigabit NICs suffered but smarter = NICs
> were developed (TSO, LRO, other TLAs) and OSs upgraded to support them=
> and I believe it is no longer a significant issue.

Are TSO and LRO going to be sufficient at 40 and 100 GbE? =A0Cores ar= en't
getting any faster. Only more plentiful.

= =A0 NICs seem to be responding by hashing incoming 5-tuples to distribute f= lows across cores.
=A0
And while it isn't the
strongest point in the world, one might even argue that the need to use
TSO/LRO to achieve performance hinders new transport protocol adoption - the presence of NIC offloads for only TCP (or UDP) leaves a new
transport protocol (perhaps SCTP) at a disadvantage.

<= /div>
=A0 True, and even UDP seems to be often blocked for anything oth= er than DNS.
--0015175cdf1871926604a32d5e76--