Re: svn commit: r251297 - head/sys/dev/xen/netfront
On 06/03/13 09:00, Andre Oppermann wrote: Author: andre Date: Mon Jun 3 13:00:33 2013 New Revision: 251297 URL: http://svnweb.freebsd.org/changeset/base/251297 Log: Specify a maximum TSO length limiting the segment chain to what the Xen host side can handle after defragmentation. This prevents the driver from throwing away too long TSO chains and improves the performance on Amazon AWS instances with 10GigE virtual interfaces to the normally expected throughput. Submitted by: cperciva (earlier version) Reviewed by:cperciva Tested by: cperciva MFC after: 1 week Modified: head/sys/dev/xen/netfront/netfront.c 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) #define RX_COPY_THRESHOLD 256 @@ -2122,6 +2123,7 @@ create_netdev(device_t dev) ifp-if_hwassist = XN_CSUM_FEATURES; ifp-if_capabilities = IFCAP_HWCSUM; + ifp-if_hw_tsomax = NF_TSO_MAXBURST; ether_ifattach(ifp, np-mac); callout_init(np-xn_stat_ch, CALLOUT_MPSAFE); Can this and r251296 be MFC'ed yet or does it need more work to pass muster? Thinking ahead to my next deployment build. Thanks. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r251297 - head/sys/dev/xen/netfront
On 06/03/13 23:00, Andre Oppermann wrote: Author: andre Date: Mon Jun 3 13:00:33 2013 New Revision: 251297 URL: http://svnweb.freebsd.org/changeset/base/251297 Log: Specify a maximum TSO length limiting the segment chain to what the Xen host side can handle after defragmentation. This prevents the driver from throwing away too long TSO chains and improves the performance on Amazon AWS instances with 10GigE virtual interfaces to the normally expected throughput. Submitted by: cperciva (earlier version) Reviewed by:cperciva Tested by: cperciva MFC after: 1 week Modified: head/sys/dev/xen/netfront/netfront.c 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? Cheers, Lawrence ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r251297 - head/sys/dev/xen/netfront
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). -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r251297 - head/sys/dev/xen/netfront
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.cMon Jun 3 12:55:13 2013 (r251296) +++ head/sys/dev/xen/netfront/netfront.cMon 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) +#defineNF_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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r251297 - head/sys/dev/xen/netfront
On Tue, Jun 04, 2013 at 23:13:54 -0700, 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). It has been a couple of years since I looked at that, but IIRC one of the issues here is that the is no way to probe for the maximum. So even once we have a FreeBSD Dom 0, we may be stuck with the limit. Or we'll have to have some other way (e.g. the xenstore) to communicate that we're running on a different type of Dom 0 and don't have the limit. Ken -- Kenneth Merry k...@freebsd.org ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r251297 - head/sys/dev/xen/netfront
On 4 June 2013 23:13, Colin Percival cperc...@freebsd.org wrote: 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. Then can you please create a This is the linux limitation rather than deriving it from a set of FreeBSD #define's ? Right now you're defining it based on the system page size _and_ some FreeBSD mbuf limit, rather than adding in the Linux versions of those as separate defines. Which honestly, they should be. Then you could add a compile time assert to ensure that the maximum segment size makes sense given both the linux constraints and the FreeBSD constraints. Otherwise looking at the code by itself isn't enough to know that it's a Linux-imposed limitation. Thanks, Adrian (Who has been knee-deep in this xen crap before, and would've appreciated these kinds of comments in the network driver.) ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r251297 - head/sys/dev/xen/netfront
Author: andre Date: Mon Jun 3 13:00:33 2013 New Revision: 251297 URL: http://svnweb.freebsd.org/changeset/base/251297 Log: Specify a maximum TSO length limiting the segment chain to what the Xen host side can handle after defragmentation. This prevents the driver from throwing away too long TSO chains and improves the performance on Amazon AWS instances with 10GigE virtual interfaces to the normally expected throughput. Submitted by: cperciva (earlier version) Reviewed by: cperciva Tested by:cperciva MFC after:1 week Modified: head/sys/dev/xen/netfront/netfront.c Modified: head/sys/dev/xen/netfront/netfront.c == --- head/sys/dev/xen/netfront/netfront.cMon Jun 3 12:55:13 2013 (r251296) +++ head/sys/dev/xen/netfront/netfront.cMon 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. */ #defineMAX_TX_REQ_FRAGS (65536 / PAGE_SIZE + 2) +#defineNF_TSO_MAXBURST ((IP_MAXPACKET / PAGE_SIZE) * MCLBYTES) #define RX_COPY_THRESHOLD 256 @@ -2122,6 +2123,7 @@ create_netdev(device_t dev) ifp-if_hwassist = XN_CSUM_FEATURES; ifp-if_capabilities = IFCAP_HWCSUM; + ifp-if_hw_tsomax = NF_TSO_MAXBURST; ether_ifattach(ifp, np-mac); callout_init(np-xn_stat_ch, CALLOUT_MPSAFE); ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
