Re: tcp mss MCLBYTES restriction

[David Borman]

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.  
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.

			-David Borman, [EMAIL PROTECTED]

On Jan 20, 2004, at 2:52 PM, Andrew Gallatin wrote:

Andre Oppermann writes:
When I was implementing the tcp_hostcache I reorganized/redid the
tcp_mss() function and wondered about that too.  I don't know if
this rounding to MCLBYTES is still the right thing to do.
I have the feeling its something from ancient days on vaxes. ;)

Would it be OK if I made this code optional via a sysctl?
Could you run some bechmarks with the current MCLBYTES rounding
and without it on 100Mbit 1.5kMTU and GigE with 9k MTU?
1.5k MTU won't matter -- it doesn't hit the rounding case anyway.
But I can certainly run some tests with 9k.
Drew



_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"