Re: AF_XDP not transmitting frames immediately

On 14/12/2021 15.57, Ong, Boon Leong wrote:
>> I suspected Boon Leong (cc) would have this hardware.
 >
> Unfortunately, my current setup in lab does not have I225 hooked-up
> and I am working remotely due to control access to intel facility.
> Perhaps, Ederson may have ready system to test?
> 
> For ZC mode, the igc driver (also true to stmmac) depends on the XSK wakeup
> to trigger the NAPI poll (igc_poll) to first clean-up Tx ring and eventually call
> igc_xdp_xmit_zc() to start submitting Tx frame into DMA engine. We have
> used busy-poll to ensure in smaller Tx frame latency/jitter.
> 
> There was another issue in stmmac that was patched [1] recently to ensure
> the driver does not perform MAC reset whenever XDP program is added
> so that between XDP socket creation, the Tx transmit does not take extra
> 2-3s due to link down/up. Jesper, are you seeing something similar in your
> app?

Yes, and it is quite annoying.

In my setup, if I AF_XDP transmit packets too early they are simply 
lost... that confused me a bit.

I wanted to ask AF_XDP maintainers:
  - What is the best way to know when AF_XDP is ready to Tx packets?

E.g. what API should I call, e.g. that blocks, until XSK socket is ready 
to transmit on?


> If yes, then it is likely because of the implementation of igc driver in mainline
> that is doing igc_down(), a little bit too aggressive in reseting MAC completely.
> 

It would be good to fix igc too, like[1].
BUT afaik it will only make the window smaller when XSK is not ready for 
TX packets.


> [1]https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/  
> 

Thanks for the link
--Jesper