Date: Wed, 26 Feb 2014 15:28:37 -0800 From: Scott Long <scott4long@yahoo.com> To: Eric van Gyzen <eric@vangyzen.net> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Sami Halabi <sodynet1@gmail.com> Subject: Re: TSO Message-ID: <3F5216B4-2434-45BF-B83C-1D4E1643EAF6@yahoo.com> In-Reply-To: <530E3211.6020805@vangyzen.net> References: <CAEW%2BogYVto3rr6LHVsG4rOuyhXt3ZWbH2kWNk-1kAmwDKROEqg@mail.gmail.com> <530E3211.6020805@vangyzen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 26, 2014, at 10:27 AM, Eric van Gyzen <eric@vangyzen.net> wrote: > On 02/26/2014 11:37, Sami Halabi wrote: >> Hi, >> I'm reading (almost) all mailing emails in mailig list... >>=20 >> Almost every / many problem in network performancr / packets loss = ended up >> suggesting disabling TSO. >>=20 >> 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? >=20 > In some cases, I have disabled TSO to [successfully] work around a bug > in a particular NIC's firmware or hardware, usually a low-end = "desktop" > gigabit NIC. >=20 The same thing happened 10-15 years ago with TCP Checksum offload. = Hardware support appeared, software support appeared, problems cropped up in = both, and it became an iterative process of identifying, disabling, and fixing. = It=92s now a solid feature that works without question (though there was a paper recently = claiming that hardware CSUM offload doesn=92t matter anymore for performance; = that=92s a different topic of discussion). Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F5216B4-2434-45BF-B83C-1D4E1643EAF6>