Date: Tue, 31 Oct 2017 12:43:02 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Cy Schubert <Cy.Schubert@komquats.com> Cc: Yuri Pankov <yuripv@gmx.com>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: NFSv3 issues with latest -current Message-ID: <YTOPR0101MB21726BD554458A4C2D190A03DD5E0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <201710291525.v9TFPXmQ052790@slippy.cwsent.com> References: Message from Rick Macklem <rmacklem@uoguelph.ca> of "Sun, 29 Oct 2017 13:13:31 -0000." <YTOPR0101MB2172093DDDCB04687D83DA49DD580@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM>, <201710291525.v9TFPXmQ052790@slippy.cwsent.com>
index | next in thread | previous in thread | raw e-mail
Cy Schubert wrote:
[stuff snipped]
>The sysctl is net.inet.tcp.tso. You can also disable tso through ifconfig
>for an interface.
>
For testing this case, I'd recommend using the sysctl. Since the net device
driver is often the culprit, that device driver might not handle the "ifconfig"
correctly either.
Btw, NFS often causes this because...
- Typically TSO is limited to a 64K packet (including TCP/IP and MAC headers).
- When NFS does reading/writing, it will do 64K + NFS, TCP/IP and MAC headers
for an RPC (or a multiple of 64K like 128K).
--> This results in tcp_output() generating a 64K TSO segment followed by a
small TCP segment (since another RPC message doesn;t usually end up
queued quickly enough to fill in the rest of the second TCP segment).
- Also, at the end of file, you can get an RPC which is just under 64K including
NFS and TCP/IP headers. (The drivers often broke when adding the MAC
header bumped this case to > 64K.)
Thanks go to Yuri for diagnosing this, rick
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB21726BD554458A4C2D190A03DD5E0>