Packet loss in ENET of imx6Dual processor

[diarmuidcollins]

I am developing an FPGA application that interfaces to an imx6Dual processor via the rgmii interface.

I am aware of the two errate related to the performance of the ENET (ERR004512 and ERR005783) https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

I think I'm seeing an issue related to ERR005783. They symptom is

1. A small packet preceding or following a large packet at high data rates (250Mbps) results in the loss of the large packet. This doesn't always happen but happens regularly.

2. The incidence of packet loss is small but always present

3. None of the ENET registers seem to be aware of the packet loss, no rx_error or overflow report is seen.

4. The issue is mitigated by shaping the traffic so that gaps of up to 27us are inserted between the packets. When I do this, I no longer see the packet loss.

Do you have more detailed information about ERR005783. Right now I am inserting the 27us between all packets but if I had more information about the exact scenario, I could tweak or implement a more targeted solution with a smaller impact on the throughput

With regard to the proposed mitigation for ERR004512 , where PAUSE frames are enabled in the Linux kernel, can you clarify if the Linux kernel builds and issues the PAUSE frames or is that handled by the processor. I am seeing quite long PAUSE delays, sometimes over 20ms. Is this expected?

[MT]

Hi @diarmuidcollins 

For ERR004512 the limitation is clear in the documentation:

" If the TX and RX peak data rate is higher than 400 Mbps, there is a risk of ENET RX FIFO overrun". Checking the BSP it does enable pause frames. The PAUSE frames are enabled and configured in the driver, but the issuing of PAUSE frames is handled in hardware. The PAUSE duration is dependent on the setting in the ENET_OPD register.

ERR005783 has a similar limitation. If small frames are used at an average line rate exceeding 400 Mbps, then the overflow issue can occur. Since ERR004512 prevents throughput higher than 400 Mbps, that likely prevents ERR005783. As you have sort of done, the workaround recommends "some flow control to ensure the line-rate burst traffic is below 400 Mbps" on shorter frames.

BR

Mark