[dpdk-users] A question about rte_pktmbuf_init() and alike functions

Wiles, Keith keith.wiles at intel.com
Tue Nov 3 19:52:49 CET 2015

On 11/3/15, 11:49 AM, "users on behalf of Александр Самойлов" <users-bounces at dpdk.org on behalf of cidjey1991 at mail.ru> wrote:

> Hi all. I'm sorry if the question is naive or stupid, but still I couldn't find the answer in the manual.

The only naive or stupid question is one you do not ask or so goes the statement :-)

>The question is: are the element init functions called just once (with the mempool creation) or are they called each time we retrieve a new element from a pool? I'm asking because I use a mempool pool with pkt_mbuf structures for generating new Ethernet frames (with IP and TCP data) and it works just fine for a while (I reckon just as long as I'm getting a new pktmbuf with rte_pktmbuf_alloc and not a recycled one) and at some point my generated frames start to have the wrong TCP ckecksum (even though TCP checksum it totally OK at first). And the strange thing is that if, for instance, mempool has 2048 elements -  my program works for 5 seconds (rough estimate), and if mempool has 4096 elements - my program works for 10 seconds. The connection is obvious. I used to believe that init() functions are called each time we retrieve an element from a mempool, but now I'm not so sure.

When you call rte_pktmbuf_pool_create() it passes rte_pktmbuf_pool_init and rte_pktmbuf_init to the rte_mempool_create() routine. The rte_pktmbuf_pool_init() is called once for the pool and the rte_pktmbuf_init() is called for each mbuf it creates from the pool at create time only.

On rte_pktbuf_alloc() it will calls __rte_mbuf_raw_alloc() and then rte_pktmbuf_reset() to reset the mbuf into a sane state. If you are trying to save mbuf state across frees then it will not work and you have to find another way. For Pktgen I wanted to keep the mbufs intact across frees and it is not super easy and you can look in Pktgen code, but I would suggest it only if really required.

I hope that helps.

>Alex Samoylov


More information about the users mailing list