From owner-freebsd-current@freebsd.org Tue Oct 31 16:46:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D4F8E5E86B for ; Tue, 31 Oct 2017 16:46:59 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 788CE80D74 for ; Tue, 31 Oct 2017 16:46:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v9VGkoMc082030; Tue, 31 Oct 2017 09:46:50 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v9VGknFO082029; Tue, 31 Oct 2017 09:46:49 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201710311646.v9VGknFO082029@pdx.rh.CN85.dnsmgr.net> Subject: Re: NFSv3 issues with latest -current In-Reply-To: To: Rick Macklem Date: Tue, 31 Oct 2017 09:46:49 -0700 (PDT) CC: Cy Schubert , Yuri Pankov , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 31 Oct 2017 16:58:26 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2017 16:46:59 -0000 > 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 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. -- Rod Grimes rgrimes@freebsd.org