Date: Tue, 20 Jan 2004 16:25:56 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: David Borman <dab@cray.com> Cc: Andre Oppermann <andre@freebsd.org> Subject: Re: tcp mss MCLBYTES restriction Message-ID: <16397.40164.341384.651639@grasshopper.cs.duke.edu> In-Reply-To: <CDB6E825-4B8C-11D8-983A-000A95D7D4C0@cray.com> References: <16397.36782.415899.626311@grasshopper.cs.duke.edu> <400D9271.1259CBC8@freebsd.org> <16397.38155.418523.634400@grasshopper.cs.duke.edu> <CDB6E825-4B8C-11D8-983A-000A95D7D4C0@cray.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Borman writes: > On the sending side, you'll tend to get your best performance when the > socket buffer is a multiple of the amount of TCP data per packet, and > the users writes are a multiple of the socket buffer. This keeps > everything neatly aligned, minimizing the number of data copies that > need to be done, and improving the chance of doing page flips. Yes, this was very handy when doing the zero-copy receives. > Rounding down a 1500 byte ethernet packet to a 1K boundary looses too > much data, but for larger MTUs, the win of keeping everything neatly > aligned can exceed the cost of not packing each packet with the maximum > amount of data. Since applications that are writing large amounts of > data to a socket will tend to be using buffers aligned on a K boundary, > using a K aligned amount of TCP data increases the chances that > everything stays aligned. Good point. But how would you feel about making it optional with it defaulting as it is now? There are special cases. For example, I think its killing me on an experimental network interface which stripes data across 2 links. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16397.40164.341384.651639>