From owner-svn-src-all@FreeBSD.ORG Thu Apr 17 23:31:50 2014 Return-Path: Delivered-To: svn-src-all@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 E6E011000; Thu, 17 Apr 2014 23:31:50 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (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 BA0CD1166; Thu, 17 Apr 2014 23:31:50 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s3HNVoU0011598; Thu, 17 Apr 2014 23:31:50 GMT (envelope-from rmacklem@svn.freebsd.org) Received: (from rmacklem@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s3HNVovb011597; Thu, 17 Apr 2014 23:31:50 GMT (envelope-from rmacklem@svn.freebsd.org) Message-Id: <201404172331.s3HNVovb011597@svn.freebsd.org> From: Rick Macklem Date: Thu, 17 Apr 2014 23:31:50 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r264630 - head/sys/net X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 23:31:51 -0000 Author: rmacklem Date: Thu Apr 17 23:31:50 2014 New Revision: 264630 URL: http://svnweb.freebsd.org/changeset/base/264630 Log: For NFS mounts using rsize,wsize=65536 over TSO enabled network interfaces limited to 32 transmit segments, there are two known issues. The more serious one is that for an I/O of slightly less than 64K, the net device driver prepends an ethernet header, resulting in a TSO segment slightly larger than 64K. Since m_defrag() copies this into 33 mbuf clusters, the transmit fails with EFBIG. A tester indicated observing a similar failure using iSCSI. The second less critical problem is that the network device driver must copy the mbuf chain via m_defrag() (m_collapse() is not sufficient), resulting in measurable overhead. This patch reduces the default size of if_hw_tsomax slightly, so that the first issue is avoided. Fixing the second issue will require a way for the network device driver to inform tcp_output() that it is limited to 32 transmit segments. Reported and tested by: csforgeron@gmail.com, markus.gebert@hostpoint.ch MFC after: 2 weeks Modified: head/sys/net/if.c Modified: head/sys/net/if.c ============================================================================== --- head/sys/net/if.c Thu Apr 17 21:43:34 2014 (r264629) +++ head/sys/net/if.c Thu Apr 17 23:31:50 2014 (r264630) @@ -74,6 +74,7 @@ #include #if defined(INET) || defined(INET6) +#include #include #include #include @@ -655,7 +656,8 @@ if_attach_internal(struct ifnet *ifp, in #if defined(INET) || defined(INET6) /* Initialize to max value. */ if (ifp->if_hw_tsomax == 0) - ifp->if_hw_tsomax = IP_MAXPACKET; + ifp->if_hw_tsomax = min(IP_MAXPACKET, 32 * MCLBYTES - + (ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN)); KASSERT(ifp->if_hw_tsomax <= IP_MAXPACKET && ifp->if_hw_tsomax >= IP_MAXPACKET / 8, ("%s: tsomax outside of range", __func__));