From owner-svn-src-head@FreeBSD.ORG Wed Jun 5 06:38:47 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D8C8693 for ; Wed, 5 Jun 2013 06:38:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3D3171A for ; Wed, 5 Jun 2013 06:38:46 +0000 (UTC) Received: (qmail 3106 invoked from network); 5 Jun 2013 07:35:55 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 5 Jun 2013 07:35:55 -0000 Message-ID: <51AEDCF1.9020109@freebsd.org> Date: Wed, 05 Jun 2013 08:38:41 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Colin Percival Subject: Re: svn commit: r251297 - head/sys/dev/xen/netfront References: <201306031300.r53D0XUx092178@svn.freebsd.org> <51AED1F3.2060003@freebsd.org> <51AED722.8000504@freebsd.org> In-Reply-To: <51AED722.8000504@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, Lawrence Stewart , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 06:38:47 -0000 On 05.06.2013 08:13, Colin Percival wrote: > On 06/04/13 22:51, Lawrence Stewart wrote: >> On 06/03/13 23:00, Andre Oppermann wrote: >>> Modified: head/sys/dev/xen/netfront/netfront.c >>> ============================================================================== >>> --- head/sys/dev/xen/netfront/netfront.c Mon Jun 3 12:55:13 2013 (r251296) >>> +++ head/sys/dev/xen/netfront/netfront.c Mon Jun 3 13:00:33 2013 (r251297) >>> @@ -134,6 +134,7 @@ static const int MODPARM_rx_flip = 0; >>> * to mirror the Linux MAX_SKB_FRAGS constant. >>> */ >>> #define MAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) >>> +#define NF_TSO_MAXBURST ((IP_MAXPACKET / PAGE_SIZE) * MCLBYTES) >> >> For posterity's sake, can you and/or Colin please elaborate on how this >> value was determined and what it is dependent upon? Could a newer >> version of Xen remove the need for this reduced limit? > > The comment above (of which only the last line is quoted in the diff) > explains it: > * This limit is imposed by the backend driver. We assume here that > * we are dealing with a Linux driver domain and have set our limit > * to mirror the Linux MAX_SKB_FRAGS constant. > > This isn't a Xen issue really; rather, it's a Linux Dom0 issue. AFAIK > there are no changes in the pipe to fix this in Linux; but this would not > be needed with a different Dom0 (e.g., a FreeBSD Dom0, if/when that becomes > possible) or if FreeBSD switched to using 4kB mbuf clusters (since at that > point we would be matching Linux and be able to fit a maximum-length IP > packet into the allowed number of fragments). We do support 4K mbufs and have done so for a long time. The problem is that socket buffer mbuf chains can be any combination of mbuf sizes and m_defrag() so far only collapses to 2K mbuf clusters. The latter can be changed but it is used in a number of places where an explicit 2K assumption may have been made (even if it shouldn't). When all them are checked m_defrag() can be changed to collapse into 4K mbufs and this "hack" removed. -- Andre