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 s= ource. > 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 noti= ceable 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>