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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 "ifcon=
fig"
correctly either.
Btw, NFS often causes this because...
- Typically TSO is limited to a 64K packet (including TCP/IP and MAC header=
s).
- When NFS does reading/writing, it will do 64K + NFS, TCP/IP and MAC heade=
rs
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 incl=
uding
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTOPR0101MB21726BD554458A4C2D190A03DD5E0>