When developing the Ethernet driver (for a RTOS) for the i.MX6Q (Sabre Platform) ENET module, I observed that the maximum receive buffer size limit for each Rx descriptor is 2032 bytes. That is, a single descriptor can hold a frame of length of up to 2032 bytes. If the descriptor length is larger than 2032 bytes, then it gets scattered into multiple descriptors.
I am not sure why this limitation is there. I couldn't find any such limitation in the i.MX6Q hardware specification. The maximum size of all receive buffers depends on the ENET_MRBR register value. According to the specification, the maximum receive buffer size (ENET_MRBR) is 14 bits long and the maximum value of the register can be 0x3FF0 (16368 bytes in decimal). But as per my observation, the register value is always considered as 11 bits long. That is why, the maximum value gets restricted to 0x7F0 bytes (2032 bytes in decimal).
Can you anyone shed some light on this?
Solved! Go to Solution.
I noticed the same, as soon as the buffer-lenght (MAXFL) exeeds 2032 all descriptors are used up showing 2048 bytes size!
So I'd say FSL should update the errata or at least specify the maximum frame-length.
Basically i.MX6 supports Jumbo frames as much as Ethernet performance
allows it; let me remind about ERR004512 (ENET: 1 Gb Ethernet MAC (ENET)
system limitation). Perhaps the problem concerns with frame splitting by Ethernet
switchers - if they are present between i.MX6 ENET and Jumbo frame source.
Thanks for the reply.
Actually, in my hardware, there is only one Ethernet port. I am afraid there is no Ethernet switch in my test network and I have connected my Windows PC directly to that port.
Also, I am getting a performance around 400 Mbps - that does not seem to be a problem.
What I am concerned about is that, as I have mentioned, no matter what, the frames are getting split into multiple frames of 2032 bytes.
You wrote that "... it gets scattered into multiple descriptors". This is expected behaviour,
when multiple buffers (descriptors) are used to store big frame.
Thank you for your help.
By pointing out that this is an expected behavior, am I to assume that I will not be able to receive individual descriptor over 2032 bytes?
Moreover, in trying to solve this issue, another thing came into my notice that whenever I am trying to transmit or receive frames over 4K (with store-and-forward enabled), the FIFO is overflowing. Is this also an expected behavior? I had to enable the store-and-forward for IP checksum offloading (which IMO is really a neat feature in this module).
If the frame (in whole) is not damaged - this is not a problem, that
several buffers (descriptors) are used. ENET of i.MX6 is a "derivative"
FIFO overflow may take place because of erratum ERR004512
(ENET: 1 Gb Ethernet MAC (ENET) system limitation).
Will the ENET module be able to receive and transmit all frames completely, with no overflow issues on the Rx side and no underflow issues on the Tx side?
Does i.MX6 supports Ethernet jumbo frames?
If yes, please let us know how to enable the same?
Can you please tell me the procedure / steps to enable the Jumbo frames?
Thanks and Regards,
Now this is a bit critical here.
As per my observation, the transmit and receive FIFO size is limited to 4KB (around) in i.MX6Q ENET controller. If it so, then it is not possible to transmit or receive a frame of length (> 4KB) when FIFO store-and-forward is enabled. Please note that store-and-forward is enabled for upper layer protocol (such as, IP) checksum offload.
I have doubt whether it is possible to enable checksum offload and jumbo frame (upto 9KB) at the same time with ENET controller.
Please respond on this.
Anath Bandhu Garai
As for 4K FIFO - this is correct, since bit field RX_SECTION_FULL of Receive FIFO Section Full Threshold (ENET_RSFL) register
allows FIFO up to 4K.
Thank you for the prompt reply here as well as Support...
I understand that the splitting of frames is not really a problem, but is there a way to solve this, such that the splitting does not happen at all?
As for the FIFO, I cannot transmit or receive frames which are larger than 4K, when Store-and-Forward is enabled. If Store-and-Forward is disabled, I am able to transmit frames frames of size upto about 8K. Could this be an issue with the Store-and-Forward module? If so, can you suggest how to solve this?