Re: AF_XDP not transmitting frames immediately

On Thu, 16 Dec 2021 08:34:23 +0000 Karlsson, Magnus wrote:
> > "Time" will tell if it is good enough (pun intended).
> > Meaning I will implement and measure it.
> > The busy-poll mode does sound like a way forward.
> > 
> > Looking at kernel code, I can see that drivers TX NAPI usually does DMA-TX
> > completion *before* transmitting new frames.  This usually makes sense,
> > but for our use-case of hitting a narrow time-slot, I worry about the jitter this
> > introduces.  I would like to see a mode/flag that would allow transmitting
> > new frames (and afterwards invoking/scheduling TX-completion, e.g. via
> > raising the softirq/NAPI).
> > Well this is future work, first I will measure current implementation.  
> 
> Maciej has been experimenting with the ice driver to do sending
> first. Completions are only done lazily when needed to make sure that
> there are always a number of descriptors available for sending. This
> yields much better throughput and is the style that DPDK uses for its
> drivers. Hopefully, this will also improve latency, though we have
> not measured that. Could be adopted for the igc driver too if that is
> the case.

I think this came up before, there was a concern that some applications
may forgo retransmiting data until they see a completions (like
skb_still_in_host_queue()).  Make sure you call out that it's a change
in behavior in the commit message and/or docs.