Date: Fri, 28 Feb 2014 13:24:52 +0800 From: Julian Elischer <julian@freebsd.org> To: Jack Vogel <jfvogel@gmail.com>, Sami Halabi <sodynet1@gmail.com>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: TSO Message-ID: <53101DA4.1060507@freebsd.org> In-Reply-To: <20140226212412.GZ92037@funkthat.com> References: <CAEW%2BogYVto3rr6LHVsG4rOuyhXt3ZWbH2kWNk-1kAmwDKROEqg@mail.gmail.com> <20140226180736.GV92037@funkthat.com> <CAFOYbckc8=j1kAU097Y=2UjFS747O49vuWYBDLmxOqXUAOkBhw@mail.gmail.com> <20140226212412.GZ92037@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/27/14, 5:24 AM, John-Mark Gurney wrote: > Jack Vogel wrote this message on Wed, Feb 26, 2014 at 10:27 -0800: >> 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 :) > But right now, when that happens, the nic just drops it instead of > telling the kernel to stop giving 6 lbs sacks.. :) It's only after a > large amount of work by various people did we even find out that this > is what was happening... so why not look at what would happen if it were people doing this.. person1 would hand person2 a 4 pound sack. all ok.. person 1 then hands person2 a 6 pound sack and person 2 replies "Ouch", that's too much!.. person 1 now knows not to do that.. until he forgets... part of the trick is knowing while assembling the packet, what interface is going to be used.. which from memory is not 100% guaranteed because routes can change... >> Why not have this limit in the interface so the stack can avoid exceeding >> it? > One of the patches proposed does that, though I hope that ALL drivers > will be properly updated when the patch hits the tree... > >> On Wed, Feb 26, 2014 at 10:07 AM, John-Mark Gurney <jmg@funkthat.com> 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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53101DA4.1060507>