i.MX6Q Sabre Platform - ENET Jumbo frame limitation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6Q Sabre Platform - ENET Jumbo frame limitation

Jump to solution
3,995 Views
binaeksarkar
Contributor II

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?

Regards

Binaek Sarkar

Labels (1)
1 Solution
2,350 Views
Yuri
NXP Employee
NXP Employee

i.MX6 ENET  does not support  Jumbo frames in store-and-forward mode.

View solution in original post

0 Kudos
12 Replies
2,350 Views
bastian_schick
Contributor IV

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.

0 Kudos
2,350 Views
Yuri
NXP Employee
NXP Employee

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.

0 Kudos
2,350 Views
binaeksarkar
Contributor II

Hello Yuri,

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.

Regards

Binaek Sarkar

0 Kudos
2,350 Views
Yuri
NXP Employee
NXP Employee

You wrote that "... it gets scattered into multiple descriptors". This is expected behaviour,

when multiple buffers (descriptors) are used to store big frame.

0 Kudos
2,350 Views
binaeksarkar
Contributor II

Yuri,

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).

Regards

Binaek Sarkar

0 Kudos
2,350 Views
Yuri
NXP Employee
NXP Employee

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"  

of FEC.
FIFO overflow may take place because of erratum ERR004512

(ENET: 1 Gb Ethernet MAC (ENET) system limitation).

0 Kudos
2,350 Views
jedes
Contributor I

Assuming:

  1. Store-and-forward is disabled (IP checksum offloading is disabled)
  2. Sufficient 2kb buffers on the Rx side
  3. A port running at 1Gb
  4. Traffic entirely made up of 9kb ethernet frames BUT globally not exceeding 400Mbps
  5. CPU has sufficient MIPS to handle all the traffic

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?

0 Kudos
2,350 Views
devarajgs
NXP Employee
NXP Employee

Hi,

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,

-Devaraj

0 Kudos
2,350 Views
anathbandhugara
Contributor I

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.

Best regards,

Anath Bandhu Garai

2,350 Views
Yuri
NXP Employee
NXP Employee

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.

2,350 Views
binaeksarkar
Contributor II

Hi Yuri,

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?

Regards

Binaek Sarkar

0 Kudos
2,351 Views
Yuri
NXP Employee
NXP Employee

i.MX6 ENET  does not support  Jumbo frames in store-and-forward mode.

0 Kudos