Date: Wed, 05 Jun 2013 08:38:41 +0200 From: Andre Oppermann <andre@freebsd.org> To: Colin Percival <cperciva@freebsd.org> Cc: svn-src-head@FreeBSD.org, Lawrence Stewart <lstewart@freebsd.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r251297 - head/sys/dev/xen/netfront Message-ID: <51AEDCF1.9020109@freebsd.org> In-Reply-To: <51AED722.8000504@freebsd.org> References: <201306031300.r53D0XUx092178@svn.freebsd.org> <51AED1F3.2060003@freebsd.org> <51AED722.8000504@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51AEDCF1.9020109>