LP-AM243: Enet Layer 2 CPSW SWITCH example is missing interrupts

Hi Hang,
 Hope you are doing well. Thanks for your question!

Would you please clarify the below points:
1. What is the MCU_PLUS_SDK version used?
2. Did you run with DEBUG build or RELEASE BUILD?
3. Any modification done on top of the out of box Enet Layer 2 CPSW SWITCH ?
4. If software is slow in picking up with interrupt rate, then we may miss rx interrupts, but we will receive more than one packet in a single interrupts. We can confirm that only by looking at CPSW statistics. Can you share the log with CPSW statistics without any CPU breakpoint? To get the statistics, you may need enter 's' in the serial terminal.
5. Please share the CPSW statistics logs after you see that packets are lost.

With regards,

Pradeep

Hi Pradeep,

Sorry for the delay.

I've reproduced customer's problem on my side. My SDK version is 09_00_00_35 and both DEBUG and RELEASE BUILD has this problem. There are almost no modification on top of the example.

Now I understand that it's normal to miss rx interrupts and one interrupt can receive multiple packets. However, I found that some packet is missing as I count them.

I use Colasoft packet builder to sent packets (The delta time here is different from the captured delta time. So I tuned the delta time here such that the captured delta time is around 0.1 ms )

and use wireshark to capture the packets.

Meanwhile, I add a few lines of code to filter and count the packet I sent (This is the only modification):

Here's the terminal log when data loss happens:

The counter was at 1094 before I sent 50 packets, and it reaches only 1129. 1129 - 1094 = 35 packets are received.

Also, there are some "Drop" messages, are they indicating packet drops?

I used software recommended in the example guide, so it might be convenient for BU experts to reproduce the problem.

All in all, my customer's goal is reach 10 packets/ms without packet loss. if this data rate is beyond this example, are there any other ways to implement this?

Thanks,

Hang.

Hi Hang,
 Thanks for share the details. it is very useful!
The examples is not optimized well to receive packets without loss. 10 packets per ms (With each packet len = 60 Bytes) is not a difficult requirement. I can suggest you the changes needed to achieve this.
- Please give me a day time for me to reproduce this and try the modification.
- Meanwhile, can you share the CPSW statistics output (you can get that by typing 's' in U ART terminal) (1) before sending 50 packets and (2) after sending 50 packets.

With regards,
Pradeep

Hi Pradeep,

Actually I have trouble printing the statistics. Typing 's' doesn't work.

Here's the full terminal log.

"link is up" is the last line before I send any packets

Seems that it didn't even reach the "Enet L2 cpsw Menu:" line where the example asks for inputs.

Can you help me with this too?

Thanks,

Hang.

Also, is there any hint for the modification? I can try to do something on my side as well.

Hi Hang,
 I plan enable software based interrupt pacing for the example, which should get good performance.
Please refer to the page - https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/enetlld_performance.html , where throughput is measured on LwIP example. I am expecting the Layer 2 example throughput to be better that of LwIP after optimization.

With regards,'Pradeep

Hi Pradeep

When i pause the core, the current instruction is pointing to "vApplicationIdleHook()"

Hi

It is expected that each packet will not result in an interrupt and hence ISR invocation as the overhead for per-packet interrupt processing is high, especially under heavy load.

The preferred approach instead would be to queue enough buffers to hardware and perform some form of batch processing. Both the HW and driver support queuing multiple buffers and the number of buffer needs to be carefully tuned based on application requirement.

As a general thumb rule, process packet in batch (eg. every 1msec in this case), and queue at least 2x the number of buffers that we will service in one batch , this will ensure that while SW (driver+application) is processing one batch, HW has another working set of buffers to receive traffic into

In this case this would imply >20buffers queued and service packets every 1 msec(set as interrupt pacing interval in driver)

Regards
Sriram

Hi Pardeep,

Thank you for the efforts, I've tested this patch on my side, and it has reached the expected data rate. However, my customer still has trouble when they put EIP connections of top of this. They claim that the number of EIP assembly connections has not met their expectation. I am still aligning with customer and trying to keep it within the scope of UDP data rate.

I am replying here to keep this thread alive.

Thank you,

Hang.