The Jumbo Ethernet Frames "Standard"

Jim:

Recently, I've been using Xilinx reference design Xapp902 as the basis for a (relatively) high speed Ethernet data transfer project. Xapp902 targets Xilinx's ML403 Evaluation Platform; the platform features the Virtex 4 FX12 device (an embedded Power PC 405 core). (jargon off)

In an attempt to conserve CPU cycles and increase data throughput, I began looking for information on Jumbo Frame implementations.


Brief Background

Data in a Local Area Network is organized hierarchically. An Ethernet or 802.2 Frame is the lowest level of data organization. And while the two are compatible, an Ethernet Frame is not the same thing as an 802.2 Frame.

Eventually, the maximum Ethernet Frame size standardized to 1518 bytes:

- 6 bytes for the destination MAC address
- 6 bytes for the source MAC address
- 2 bytes for length or type information (this is the key difference between Ethernet & 802.2)
- 1500 bytes (maximum) for data
- 4 bytes for a CRC checksum on the Ethernet Frame

At the hardware level, (the MAC and PHY layers), dedicated hardware components are responsible for transmission, reception, and error detection in these frames; however, the System CPU is generally responsible for orchestrating data handling once an entire packet becomes available.

This scheme was fine in the days of 10 Mbit/sec Ethernet, but as network speeds increase, the CPU has less & less time for orchestration, and spends an increasingly higher percentage of its time just handling network traffic. At Gigabit Ethernet speeds, packets arrive 100 times faster than they did with the old 10 Mbit/sec protocol... Enter the Jumbo Frame.

The Jumbo Frame

This problem was recognized years ago. In response, engineers proposed tweaking the meaning of the length/type field in the Ethernet/802.2 frame. They proposed letting the length/type field contain data for Frames > 1500 bytes.

By increasing the Frame size (to approx. 9 KBytes), the network processing burden on the CPU could be reduced proportionately. Makes sense, doesn't it? The problem was that there was already too much networking infrastructure in place by then, and Jumbo Frames were largely incompatible with that infrastructure. Consequently, the Jumbo Frame proposal was rejected.

But, that didn't stop Jumbo Frames from being implemented in systems; they've just been declared as proprietary. A proprietary non-standard standard. Oh boy.

I'm not sure how many non-standard implementations there are out there; in the Xilinx Ethernet device driver code I've seen, there are some values that can be changed in the MAC hardware to allow receipt & transmission of Jumbo Frames. But it looks as if the length/type field must be used to indicate Frame size.

Of course, the resulting packets would non-standard, which means that they could be rejected by other devices on the network. Not good if I need to move data through switches and routers.

Given the hassles described above, I've decided to stick with regular 1518 byte Frames; but, I would like to know if and how other devices and systems are handling Jumbo Frames. Do they just "flip the Jumbo hardware switch" and assume that the length/type field represents the Frame size?

My understanding is that Jumbo Frames are part of the Gigabit Ethernet standard, but I haven't seen anything documenting this.