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.
|