On Thu, Oct 10, 2024 at 10:12 AM Alan Beadle <ab.bea...@gmail.com> wrote: > > On Sun, Oct 6, 2024 at 6:18 PM Stephen Hemminger > <step...@networkplumber.org> wrote: > > > > Drivers are free to hold onto transmitted mbuf's indefinitely. > > Since DPDK does not use interrupts for normal Tx, the driver has to defer > > doing cleaning up either on next Tx or sometimes Rx. There is a Tx threshold > > that may impact some drivers, but not all. > > Stephen, > > How would I attempt to set this threshold to see if it impacts the > driver that I am using? I cannot find any EAL parameters that seem to > correspond to this. > > Having to re-allocate a new mbuf every time will hurt performance, > especially since most of the packet header values will not be changing > across packets but will need to be reinitialized in every newly > allocated mbuf. I had really hoped to recycle a set of <100 or so > mbufs.
(Stephen, sorry for the double email, forgot to reply-all). I believe I have found a solution. I'll have to investigate the impact on performance later but advice/analysis is appreciated. I initialized the pool with a limit of 128 tx descriptors and set the tx ring buffer size to match. Once the ring is full, the NIC seems to free things as it goes, resulting in having no sent-but-unfreed mbufs most of the time. Please let me know if there's any major issue with this approach and if there's anything else I can do. At least this behaves in a way that I can design my app like I planned and I'm hoping it results in non-bursty latencies and good performance. -Alan
