From owner-freebsd-net@FreeBSD.ORG Thu Feb 27 00:49:52 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6268F842 for ; Thu, 27 Feb 2014 00:49:52 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 20D5D101E for ; Thu, 27 Feb 2014 00:49:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUEABGLDlODaFve/2dsb2JhbABag0FXgwOnPZVwT4EtdIInAQEBAwEBAQEgKyALGw4KAgINGQIjBgEJFBIGCAcEARwEh0QDCQgNqQaZKA2HMxeBKYsVgTQLBQIBGzQHgm6BSQSFa4NejBdpBoMZiy+FR4NLHjF8QQ X-IronPort-AV: E=Sophos;i="4.97,551,1389762000"; d="scan'208";a="100707786" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 26 Feb 2014 19:49:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D8DC3B4035; Wed, 26 Feb 2014 19:49:44 -0500 (EST) Date: Wed, 26 Feb 2014 19:49:44 -0500 (EST) From: Rick Macklem To: Jack Vogel Message-ID: <1445354566.13933652.1393462184879.JavaMail.root@uoguelph.ca> In-Reply-To: Subject: Re: TSO MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - IE8 (Win)/7.2.1_GA_2790) Cc: FreeBSD Net , Sami Halabi , Scott Long X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 00:49:52 -0000 Jack Vogel wrote: > Nah that wouldn't be very practical would it :) I was thinking the > max > segment value could be > kept in the interface struct, but as I think about it I guess that > wouldn't > really help. So, you > have other ideas Scott?? > > Jack > I won't pretend to be Scott, but I have an untested patch that allows the device to specify its maximum # of segments for transmit (something like if_hw_maxtsoseg to go along with if_hw_maxtso) and then tcp_output() uses that along with if_hw_maxtso to limit the segment size handed to the device. (I don't have any hardware that does TSO, so I can't do anything more with it. If anyone wants to look at it, email and I'll send you a copy.) John-Mark Gurney looked at it and mentioned a concern w.r.t. "fixing the drivers that could handle long mbuf chains". I think this means that the default would need to be large instead of 30. rick > > > On Wed, Feb 26, 2014 at 1:13 PM, Scott Long > wrote: > > > Are you proposing that the network stack track the physical memory > > segment > > details of the mbufs as they are formed and chained together? > > > > Scott > > > > On Feb 26, 2014, at 10:27 AM, Jack Vogel wrote: > > > > > Drivers have to work with whatever the requirements/limitations > > > of the > > > hardware, > > > if you have a 5 lb sack you shouldn't be surprised if some drops > > > when you > > > shove > > > 6 lbs at it :) > > > > > > Why not have this limit in the interface so the stack can avoid > > > exceeding > > > it? > > > > > > Jack > > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 10:07 AM, John-Mark Gurney > > > > > wrote: > > > > > >> Sami Halabi wrote this message on Wed, Feb 26, 2014 at 19:37 > > >> +0200: > > >>> I'm reading (almost) all mailing emails in mailig list... > > >>> > > >>> Almost every / many problem in network performancr / packets > > >>> loss ended > > >> up > > >>> suggesting disabling TSO. > > >>> > > >>> I wonder why.. Is it a bug in the implementation? Or bybdesign? > > >>> What are the usecases that TSO is needed? Myabe it should be > > >>> disabled > > bt > > >>> default? > > >> > > >> It looks like most of the problems are in drivers that don't > > >> handle > > >> packets with a large number of segments properly... The problem > > >> is > > >> that some drivers limit to how segments a packet can be broken > > >> into, and > > >> then if they receive such a packet, instead of doing their > > >> darnest to > > >> deliver it, they drop it... > > >> > > >> There are some patches that help address the issue... > > >> > > >> Drivers should complain more loudly when a packet gets dropped > > >> by the > > >> driver, since it is likely that the OS may retry the same > > >> packet, > > >> just to have it fail, though sometimes it'll try a different > > >> set, and > > >> it might go through, so all the user may notice is a slight lag > > >> if > > >> they notice anything at all... > > >> > > >> -- > > >> John-Mark Gurney Voice: +1 415 225 > > >> 5579 > > >> > > >> "All that I will do, has been done, All that I have, has > > >> not." > > >> _______________________________________________ > > >> freebsd-net@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > > >> To unsubscribe, send any mail to > > >> "freebsd-net-unsubscribe@freebsd.org" > > >> > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to > > > "freebsd-net-unsubscribe@freebsd.org" > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >