On 3. Jun 2012, at 16:51 , Colin Percival wrote: > On 05/30/12 08:30, Andrew Gallatin wrote: >> On 05/30/12 10:59, Colin Percival wrote: >>> The Xen virtual network interface has an issue (ok, really the issue is with >>> the linux back-end, but that's what most people are using) where it can't >>> handle scatter-gather writes with lots of pieces, aka. long mbuf chains. >>> This currently bites us hard with TSO enabled, since it produces said long >>> mbuf chains. >> >> I think a better approach would be to have a limit on the size of the >> pre-segmented TCP payload size sent to the driver. I tend to think >> that this would be more generically useful, and it is a better match >> for the NDIS APIs, where a driver must specify the max TSO size. I >> think the changes to the TCP stack might be simpler (eg, they >> would seem to jive better with the existing "maxmtu" approach). >> >> I think this could work for you as well. You could set the Xen max >> tso size to be 32K (derived from 18 pages/skb, multiplied by a typical >> 2KB mbuf size, with some slack built in). If the chain was too large, >> you could m_defrag it down to size. > > I've attached a new patch which: > 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct > ifnet, > 2. sets these in netfront when the IFCAP_TSO4 flag is set, > 3. extends tcp_maxmtu to read this value, > 4. adds a tx_tso_mss field to struct tcpcb, > 5. makes tcp_mss_update set tx_tso_mss using tcp_maxmtu, and > 6. limits TSO lengths to tx_tso_mss in tcp_output.
general question - what happens in the IPv6 case? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
