Messages in this thread | | | Date | Wed, 4 Feb 2009 20:28:20 +0100 | From | Willy Tarreau <> | Subject | Re: [PATCH v2] tcp: splice as many packets as possible at once |
| |
On Wed, Feb 04, 2009 at 11:19:06AM -0800, Roland Dreier wrote: > > And the arbitrary choice of 9k for jumbo frames was total crap too. > > It's clear that no hardware designer was involved in the process. > > They have to stuff 16kB of RAM on a NIC to use only 9. And we need > > to allocate 3 pages for slightly more than 2. 7.5 kB would have been > > better in this regard. > > 9K was not totally arbitrary. The CRC used for checksumming ethernet > packets has a probability of undetected errors that goes up about > 11-thousand something bytes. So the real limit is ~11000 bytes, and I > believe ~9000 was chosen to be able to carry 8K NFS payloads + all XDR > and transport headers without fragmentation.
Yes I know that initial motivation. But IMHO it was a purely functional motivation without real considerations of the implications. When you read Alteon's initial proposal, there is even a biased analysis (they compare the fill ratio obtained with one 8k frame with that of 6 1.5k frames). Their own argument does not stand with their final proposal! I think that there might already have been people pushing for 8k and not 9 by then, but in order to get wide acceptance in datacenters, they had to please the NFS admins.
Now it's useless to speculate on history and I agree with Davem that we're wasting our time with this discussion, let's go back to the keyboard ;-)
Willy
| |