Part Number: AM623
The test found that the maximum delay between rx and tx in the same cycle of Ethercat is 200us
Expected to control the maximum delay between rx and tx in the same cycle of Ethercat within 50us
Make modifications in the CPSW driver, and handle Ethercat（0x88A4） and Profinet(0x8892) messages in the interrupt thread.
Ordinary messages use napi framework
Without any real-time tunings or other Ethernet optimizations to the Linux OS, after 16+ hour runtime ~200us for max RX and TX time for running CODESYS EtherCAT is expected.
With some XDP zero copy enabled on CPSW driver and making sure you are using a version of the CODESYS application that supports XDP zero copy, after 16+ hour runtime max RX and TX time can be reduced ~100us (from 16x I/O EtherCAT subdevice/slave setup). At startup (<10min runtime), the max RX and TX time can be as low as ~30us.
Expected to control the maximum delay between rx and tx in the same cycle of Ethercat within 50us
Make modifications in the CPSW driver, and handle Ethercat（0x88A4） and Profinet(0x8892) messages in the interrupt thread.
Ordinary messages use napi framework
Reducing to 50us max TX and RX time for long runtime may be difficult without additional real-time tunings (e.g. strategically placing IRQs on different CPU cores, isolated processes from interfering for EtherCAT related interrupts, etc).
This request to modify the CPSW driver beyond the improvements that XDP zero copy in the CPSW driver can already provide might not give as good of latency reduction than you may expect. In general, since XDP zero copy means packets are directly passed from the driver to the user space application, directly by-passing the Linux Kernel networking stack layers, and interrupt-driven handling like you are suggesting will still involve passing through the Linux Kernel networking stack layers, there will still be latency involved when passing through all these layers.
Additionally, with the interrupt-driven approach, it will cause high CPU load which can impact the performance and processing of not only CODESYS EtherCAT applications but other applications that are running on the system. With XDP zero copy, the CPU load won't be as high as the interrupt-driven approach. The interrupt-driven approach is useful when the amount of traffic/number of packets is low. But in an EtherCAT use-case there may be a lot of packets being continuously received and transmitted in a short amount of time which can prevent the CPU from handling anything else while EtherCAT packets are passing through.
