Date: Tue, 9 Apr 2013 07:20:35 +0000 From: "Eggert, Lars" <lars@netapp.com> To: "<pyunyh@gmail.com>" <pyunyh@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: enable tcpdump GUESS_TSO flag? Message-ID: <8EF28976-C8CF-43D0-B6D0-7547014E1AB9@netapp.com> In-Reply-To: <20130408051836.GA1526@michelle.cdnetworks.com> References: <0A5ED929-C148-45C3-8576-C31D2C05AB04@netapp.com> <20130408051836.GA1526@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Apr 8, 2013, at 7:18, YongHyeon PYUN <pyunyh@gmail.com> wrote: > I don't have strong option on enabling that flag but I think it > would be even better to have an option to enable/disable that > feature(default off). I agree that would be the better solution, but it's a larger patch to the source. > em(4) controllers require IP length should > be 0 before controller performs TSO operation. fxp(4) controllers > requires IP length should be set to the IP length of the first TCP > segment after TSO operation. bpf listeners see the modified packet > so it can confuse them. AFAIK, except em(4)/fxp(4) controllers, no > other controllers in tree have such limitation with TSO. Enabling > GUESS_TSO flag may make it hard to debug network/driver issues I > guess. Not sure. Yeah, you wouldn't see "IP bad-len 0" messages anymore in traces, but instead those packets would contain garbage. That should still be noticeable to someone looking into the dump. Lars
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8EF28976-C8CF-43D0-B6D0-7547014E1AB9>