Date: Wed, 26 Feb 2014 13:13:36 -0800 From: Scott Long <scott4long@yahoo.com> To: Jack Vogel <jfvogel@gmail.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Sami Halabi <sodynet1@gmail.com> Subject: Re: TSO Message-ID: <D42D04B4-C79C-4679-A70A-9AFF7081CADB@yahoo.com> In-Reply-To: <CAFOYbckc8=j1kAU097Y=2UjFS747O49vuWYBDLmxOqXUAOkBhw@mail.gmail.com> References: <CAEW%2BogYVto3rr6LHVsG4rOuyhXt3ZWbH2kWNk-1kAmwDKROEqg@mail.gmail.com> <20140226180736.GV92037@funkthat.com> <CAFOYbckc8=j1kAU097Y=2UjFS747O49vuWYBDLmxOqXUAOkBhw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jfvogel@gmail.com> 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 <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... >> >> -- >> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D42D04B4-C79C-4679-A70A-9AFF7081CADB>
