Date: Wed, 1 Nov 2017 03:46:46 +0300 From: Yuri Pankov <yuripv@gmx.com> To: Rick Macklem <rmacklem@uoguelph.ca>, "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: Cy Schubert <Cy.Schubert@komquats.com>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: NFSv3 issues with latest -current Message-ID: <1c0ca4f6-04ee-944c-e910-3a10ada87d9e@gmx.com> In-Reply-To: <YTOPR0101MB217217C4E0F12EF679A7FB83DD5F0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM> References: <YTOPR0101MB21726BD554458A4C2D190A03DD5E0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM> <201710311646.v9VGknFO082029@pdx.rh.CN85.dnsmgr.net> <YTOPR0101MB217217C4E0F12EF679A7FB83DD5F0@YTOPR0101MB2172.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Nov 2017 00:27:50 +0000, Rick Macklem wrote: > Rodney W. Grimes wrote: > [stuff snipped] >> I wrote: >>> 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 >> >> Just a thought, not asking anyone to write one :-) >> >> It would be handy to have some sh(1) scripts that can exercise this bug >> case and have it readily avaliable to network driver authors for testing >> the tso (or other large segment) code. > You can't easily reproduce this from userland. It depends on the way NFS fills in > the mbuf chain for I/O RPCs. (iSCSI does something similar.) > > However, if your shell script does an NFS mount and the writes/reads a > file just under 64K in size on the mount... Yes, I should be able to test this, it's not a production in any case. And just in case, it's not related to nfs, sorry for jumping to guesses, Rick, scp behaves the same, giving a fair transfer rate of 10kbps, and 10MBps with that change backed out.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1c0ca4f6-04ee-944c-e910-3a10ada87d9e>