Hi Parthiban I hope I send this in the right context as it is not related to just one patch or some specific code. I conducted UDP load testing using three i.MX8MM boards in conjunction with the LAN8651. The setup involved one board functioning as a server, which is just echoing back received data, while the remaining two boards acted as clients, sending UDP packets of different sizes in various bursts to the server. Due to hardware constraints, the SPI bus speed was limited to 15 MHz, which might have influenced the results. During the tests I experienced some issues: - The boards just start receiving after first sending something (ping another board). Some measurements showed that the irq stays asserted after init. This makes sense as far as I understand the chapter 7.7 of the specification, the irq is deasserted on reception of the first data header following CSn being asserted. As a workaround I trigger the thread at the end of oa_tc6_init. - If there is a lot of traffic, the receive buffer overflow error spams the log. - If there is a lot of traffic, I got various kernel panics in oa_tc6_update_rx_skb. Mostly because more data to rx_skb is added than allocated and sometimes because rx_skb is null in oa_tc6_update_rx_skb or oa_tc6_prcs_rx_frame_end. Some debugging with a logic analyzer showed that the chip is not behave correctly. There is more bytes between start_valid and end_valid than there should be. Also there seems to be 2 end_valid without a start_valid between. What is common is that the incorrect frame starts in a chunk where end_valid and start_valid is set. In my opinion its a problem in the chip (maybe related to the errata in the next point) but the driver should be resilent and just drop the packet and not cause a kernel panic. - Sometimes the chip stops working. It always asserts the irq but there is no data (rca=0) and also exst is not active. I found out that there is an errata (DS80001075) point s3 that explains this. I set the ZARFE bit in CONFIG0. This also fixes the point above. The driver now works since about 2.5 weeks with various load with just one loss of frame error where I had to reboot the system after about 4 days. Is there a reason why you removed the netdev watchdog which was active in v2? Thanks, Benjamin Bigler
