Murali Karicheri <m-kariche...@ti.com> :
> The internal memory or FIFO can store only up to 3 MTU sized packets. So that
> has to
> be processed before PRU gets another packets to send to CPU. So per above,
> it is not ideal to run NAPI for this scenario, right? Also for NetCP we use
> about 128 descriptors with MTU size buffers to handle 1Gbps Ethernet link.
> Based on that roughly we would need at least 10-12 buffers in the FIFO.
> Currently we have a NAPI implementation in use that gives throughput of
> 95Mbps for
> MTU sized packets, but our UDP iperf tests shows less than 1% packet loss for
> offered traffic of 95Mbps with MTU sized packets. This is not good for
> network using HSR/PRP protocol for network redundancy. We need to have zero
> loss for MTU sized packets at 95Mbps throughput. That is the problem
Imvho you should instrument the kernel to figure where the excess latency that
prevents NAPI processing to take place within 125 us of physical packet
> As an experiment, I have moved the packet processing to irq handler to see if
> can take advantage of CPU cycle to processing the packet instead of NAPI
> and to check if the firmware encounters buffer overflow. The result is
> with no buffer overflow seen at the firmware and no packet loss in the iperf
> But we want to do more testing as an experiment and ran into a uart console
> up after running traffic for about 2 minutes. So I tried enabling the DEBUG
> options to get some clue on what is happening and ran into the trace I shared
> earlier. So what function can I use to allocate SKB from interrupt handler ?
Is your design also so tight on memory that you can't even refill your own
software skb pool from some non-irq context then only swap buffers in the
irq handler ?