From owner-freebsd-net@FreeBSD.ORG Sun Jul 6 23:27:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 656EBC3D for ; Sun, 6 Jul 2014 23:27:47 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D4242038 for ; Sun, 6 Jul 2014 23:27:46 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 4D6C716038B; Sun, 6 Jul 2014 16:27:40 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id CF89F160209 for ; Sun, 6 Jul 2014 16:27:37 -0700 (MST) Message-ID: <53B9DB69.1070705@pinyon.org> Date: Sun, 06 Jul 2014 16:27:37 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: NFS client READ performance on -current References: <870285181.7082888.1404435061501.JavaMail.root@uoguelph.ca> In-Reply-To: <870285181.7082888.1404435061501.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 23:27:47 -0000 On 07/03/14 17:51, Rick Macklem wrote: > Well, I took a quick look at the driver and it does use m_defrag(), but > I think that the "retry:" label it does a goto after doing so might be in > the wrong place. > > The attached untested patch might fix this. > > Is it convenient to build a kernel with this patch applied and then try > it with TSO enabled? Patch applied to both client and server (both nics use if_em), net.inet.tcp.tso=1 With a cold 5GB transfer, I see a fairly steady mid 60s MB/s reading on the client. I'm happy BTW. The throughput is now sufficient for my application. HTH, Russell > > rick > ps: It does have the transmit segment limit set to 32. I have no idea if > this is a hardware limitation. >