From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp151.iad.emailsrvr.com (smtp151.iad.emailsrvr.com [207.97.245.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D0CBB202224 for ; Sat, 23 Jun 2012 15:33:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 4A7283002DF; Sat, 23 Jun 2012 18:33:14 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy14.wa-web.iad1a (legacy14.wa-web.iad1a.rsapps.net [192.168.4.100]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 2FA47300286; Sat, 23 Jun 2012 18:33:14 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy14.wa-web.iad1a (Postfix) with ESMTP id 199BA2630002; Sat, 23 Jun 2012 18:33:14 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sat, 23 Jun 2012 18:33:14 -0400 (EDT) Date: Sat, 23 Jun 2012 18:33:14 -0400 (EDT) From: dpreed@reed.com To: "Robert Bradley" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <4FE6397A.4080703@gmail.com> References: <1340395875.353911244@apps.rackspace.com> <4FE4D882.50308@gmail.com> <1340479742.390625935@apps.rackspace.com> <4FE6397A.4080703@gmail.com> Message-ID: <1340490794.10381992@apps.rackspace.com> X-Mailer: webmail7.0 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Fwd: [PATCH] ag71xx: Added support for baby-jumbo packets. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:33:16 -0000 All true, but most TCP's these days support Path MTU discovery, and most ap= ps that can use > 1500 bytes test the path before using, even if using UDP.= =0A=0ASetting lower MTUs on a home network, etc. is useful only if the larg= e MTUs are problematic on the links involved. A 9k MTU is bad on a 128k I= SDN link, for sure.=0A=0APreserving legacy limits because there were proble= ms with them 5 years ago is a sure way to lock yourself in to problems. D= rivers shouldn't have the limits compiled in, instead you can use commands = to shrink MTU if need to do so exists.=0A=0A-----Original Message-----=0AFr= om: "Robert Bradley" =0ASent: Saturday, June 23,= 2012 5:47pm=0ATo: cerowrt-devel@lists.bufferbloat.net=0ASubject: Re: [Cero= wrt-devel] Fwd: [PATCH] ag71xx: Added support for baby-jumbo packets.=0A=0A= On 23/06/12 20:29, dpreed@reed.com wrote:=0A> I find it curious that packet= aggregation is done in 802.11n standards, but that the packets are limited= to 1540. I bet that limit may not be there in all Atheros NICs, and mayb= e not in this one. Will investigate now that I'm curious.=0A>=0A>=0A=0AThe= patch only affects the wired Ethernet driver, so 802.11n packet =0Aaggrega= tion does not apply here. TSO and friends could apply in theory, =0Abut ei= ther is unsupported or disabled in this case. The wireless side =0Ais hand= led by the ath9k driver instead, where I know nothing about the =0Aupper li= mits on MTU. Depending on the cards used by the clients, the =0Amaximum MT= U may be limited to 1500 even if the ath9k driver can cope.=0A-- =0ARobert = Bradley=0A_______________________________________________=0ACerowrt-devel m= ailing list=0ACerowrt-devel@lists.bufferbloat.net=0Ahttps://lists.bufferblo= at.net/listinfo/cerowrt-devel=0A