Ethernet over USB framing
A general discussion of framing issues when transporting Ethernet frames over USB
Contents |
Background
USB has various speed variations and various transfer types, yielding maximum packet sizes ranging from 64 to 1024 bytes.
Ethernet frames, on the other hand, can be between 64 and 1518 bytes (more if using VLAN tagging), not including Jumbo frames (up to 9000 bytes).
The maximum data transfer rate for High-Speed USB (480Mbps) is using Bulk transfers which allow up to 512 bytes per USB transaction in High-Speed mode. For Full-Speed USB (12Mbps), the maximum Bulk transfer packet size is 64 bytes.
Therefore, any given Ethernet frame transported across High-Speed USB using Bulk transfers could utilise between 1 and 3 USB packets. Conversely, there could be up to eight minimum-sized Ethernet frames in a single 512 bytes High-Speed USB Bulk packet (if frame-stuffing is supported by the Ethernet-over-USB driver).
Often, High-Speed USB packets will be shoved into a FIFO at the device end. Individual USB packet boundaries may be preserved, but they may lose some resolution, eg. unable to differentiate between an odd length packet and the next-larger even length packet if the FIFO output is 16-bits wide.
Clearly, a robust framing mechanism needs to be employed.
Framing Mechanisms
In general, framing techniques can be divided into three groups:
- use of a frame-length prefix
- use of a special reserved "start-of-frame" token, which must then be "escaped" out of the data path
- use of time-outs
Continuous CRC
Using this mechanism, the CRC is continuously calculated for incoming (Host to NetFPGA) packets, on both odd and even boundaries. If ever either is valid at the end of a FIFO transfer (512 bytes/256 words, or partial), then there is a good chance that this is the end of the frame. Using a 32bit CRC, there is a statistically small chance that random data may end up as a valid CRC on 512 byte boundaries. Can we model this?
Prepend 2-byte size
This is an extension of the NetFPGA Padded Switch project from the NetFPGA 2012 Summer Camp in which the various inputs to the switch add 2 bytes to each frame to re-align all the data fields to better align with the 8-byte wide pipeline.
Here, instead of padding the Ethernet frame as it arrives at the NetFPGA 1G, we add a two-byte length field to the start of the frame at the USB Host in the Kernel driver. When the frame arrives at the NetFPGA, the two bytes are used to determine the frame length and are passed through the NetFPGA infrastructure as padding, but do not participate in CRC validation, etc.
Overwrite part of source MAC address
The 6-byte Ethernet frame source MAC address is pretty much constant for any given interface, but is transported across the Host-to-NetFPGA transport anyway.
We could overwrite the most significant 2 bytes of the source MAC address, which the NetFPGA code can then remove and replace with the constant 2 bytes in use as the frame is received.
For outgoing frames (NetFPGA to Host), we overwrite the destination MAC address, being careful to preserve any data regarding possible broadcast or multicast destination addresses.
