Date: Wed, 26 Feb 2014 13:28:20 -0800 From: Jack Vogel <jfvogel@gmail.com> To: Scott Long <scott4long@yahoo.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Sami Halabi <sodynet1@gmail.com> Subject: Re: TSO Message-ID: <CAFOYbcmfRiwuhrhJkx2pY_iTFXX92T5SvNth0w7a_vL%2BR0W9%2BA@mail.gmail.com> In-Reply-To: <D42D04B4-C79C-4679-A70A-9AFF7081CADB@yahoo.com> References: <CAEW%2BogYVto3rr6LHVsG4rOuyhXt3ZWbH2kWNk-1kAmwDKROEqg@mail.gmail.com> <20140226180736.GV92037@funkthat.com> <CAFOYbckc8=j1kAU097Y=2UjFS747O49vuWYBDLmxOqXUAOkBhw@mail.gmail.com> <D42D04B4-C79C-4679-A70A-9AFF7081CADB@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 On Wed, Feb 26, 2014 at 1:13 PM, Scott Long <scott4long@yahoo.com> 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 <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?CAFOYbcmfRiwuhrhJkx2pY_iTFXX92T5SvNth0w7a_vL%2BR0W9%2BA>