Jumbo Ethernet Frames

More or less where they were before?

It is about as wide as it gets now.

I believe so. I believe that all the Intel and Broadcom NICs support them.

Switches can be a bit interesting though - I seem to have heard that some will say they support "jumbo frames" when their support is for something There are some no-ack protocols that could benefit greatly from not

There is still the issue of making sure that everything from one end to the other supports JF. In the TCP/IP space, I would posit that JF is being supplanted by Large Send/TSO - it allows the TCP stack to send large segments down the stack that the NIC resegments into packets which fit the network. Now there is no need for JF support end-to-end - although at the cost of not getting all the performance benefits of JF.

And then one can start talking about TOE...

rick jones

I have known 10baseT cards to support them, as they were designed with 16 bit registers. Don't count on them going through any equipment you don't supply, though.

The Internet likely won't be changing anytime soon. If you want to do it in the privacy of your own net, no-one will stop you. As far as I understand it there is work to speed up 1500 octet traffic such that the differences will be small.

-- glen

They were not standarised.

Never.

Yes.

best regards Patrick

The internet shouldn't be a factor, as it'd designed to work with a variety of technologies, including those that support much bigger frames. For example, years ago I used to run on a token ring network, using 4K frames. IP will either fragment the packets or use MTU discovery to limit packet sizes as necessary, to pass through the smallest MTU along the path. Even with 1500 byte MTU, this occurred because some paths through the internet used even smaller (~570 bytes IIRC) frames. IP is supposed to be independent of the underlying hardware.

I guess I should have mentioned: I am experimenting with a new protocol stack (new layers, new everything).

Layer 2 of my protocol stack disallows fragementation. However, there are some instances where 3K is the ideal minimum "useful payload" size, and 7800 would be the minimum size for efficient amortization of overhead cause by security and other mechanims. So you can imagine how I would be interested in 9K buffers.

I realize that the entire 'Net would have to change to make this feasible, but I would just be content in knowing that the capability 9K is present in most NICs. Naturally, there are other ways to support the no-fragmentation requirement.

-Le Chaud Lapin-

Again it shouldn't make any difference. With IPv4 you can use MTU discovery to limit your packet size. And if you don't some downstream router will fragement the packets for you. With IPv6, you'll have to use MTU discovery or fragmentation at the source.