Prevent rte_eth_tx_burst from freeing mbufs

Prevent rte_eth_tx_burst from freeing mbufs

[Antonio Di Bacco]

Is it possibile to take full control of mbuf and avoid the mbuf to be
freed after it has been sent?

RE: Prevent rte_eth_tx_burst from freeing mbufs

[Van Haaren, Harry]

> -----Original Message-----
> From: Antonio Di Bacco <a.dibacco.ks@gmail.com>
> Sent: Thursday, March 30, 2023 10:11 PM
> To: users@dpdk.org
> Subject: Prevent rte_eth_tx_burst from freeing mbufs

Hi Antonio,

> Is it possibile to take full control of mbuf and avoid the mbuf to be
> freed after it has been sent?

Yes it is; technically the TX of DPDK's ethdev doesn't *free* the packet, it decreases the mbuf refcnt by 1.
If that happened to be the last user of that mbuf, then the mbuf will be freed (so returned to the mempool it came from).

So in order to keep the mbuf "around" while also TX-ing it, you can update its "refcnt" value.
There is a helper function to do this correctly (e.g, walk chains for multi segment mbufs!):
https://doc.dpdk.org/api/rte__mbuf_8h.html#a7ac5629940550649a2ef40029f5ad21a

Just adding 1 to the refcnt will keep the packet "in use" and not return it to the mempool, until the code where you own the "added refcnt" calls rte_pktmbuf_free(), which will reduce the refcnt from 1 -> 0, and return to the mempool then.

Please note; updating the refcnt keeps access to the *same* packet memory - it is NOT a copy. If you modify the packet after calling rte_eth_tx_burst(), you have a race condition. The TX on the NIC may take some time to complete (depends on NIC descriptor ring size, link-speed, TXQ schedulers etc..). I recommend to consider the "refcnt updated" packet handle a "read only" mbuf.

Hope that helps, -Harry