[dpdk-users] mbuf free cnt not decreasing

[Wiles, Keith]

From: Javier Coleto Fernández <javicoleto44 at gmail.com<mailto:javicoleto44 at gmail.com>>
Date: Monday, April 18, 2016 at 11:41 AM
To: Keith Wiles <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>
Cc: Andriy Berestovskyy <aber at semihalf.com<mailto:aber at semihalf.com>>, users <users at dpdk.org<mailto:users at dpdk.org>>
Subject: Re: [dpdk-users] mbuf free cnt not decreasing


2016-04-18 18:29 GMT+02:00 Wiles, Keith <keith.wiles at intel.com<mailto:keith.wiles at intel.com>>:
>Javier,
>That was just our guess, you might have the leak somewhere else...
>
>Andriy
>
>On Mon, Apr 18, 2016 at 6:01 PM, Javier Coleto Fernández
><javicoleto44 at gmail.com<mailto:javicoleto44 at gmail.com>> wrote:
>> This is exactly what I'm doing at the moment, but the free count (both the
>> rte_mempool_free_count() and rte_ring_free_count()) keeps increasing
>> nonetheless.

Check to make sure you are not increasing the reference count in the mbuf, these two are the most common places to lose packets.

I don't make any call to reference count changing functions (like rte_mbuf_refcnt_update/set) but, is there any other way this reference count could end up having a "bad" value?

The one way is overwriting the value in the mbuf that I know of.


Also check your loops to make sure you are not breaking out of the packet processing loops too soon and skipping some packets. In one case I have seen someone converted a while loop into a for loop and forgot to remove the i++ some place in the body of the code. Try adding counter on your code to see if you are missing processing or freeing the packets.

I would not expect the DPDK code to be the problem, so focus on your code is all I can tell you.

>>
>> Regards,
>> Javier
>>
>> 2016-04-18 17:57 GMT+02:00 Andriy Berestovskyy <aber at semihalf.com<mailto:aber at semihalf.com>>:
>>>
>>> On Mon, Apr 18, 2016 at 5:34 PM, Javier Coleto Fernández
>>> <javicoleto44 at gmail.com<mailto:javicoleto44 at gmail.com>> wrote:
>>> > Basing on what you say, is that return value supposed to be less than
>>> > 'n' in
>>> > case the ring is filled up or do I have to check the ring size before
>>> > calling rte_eth_tx_burst()?
>>>
>>> You just have to check the return value and free the unsent mbufs.
>>> Here is an example:
>>>
>>> ret = rte_eth_tx_burst(port, queueid, m_table, n);
>>> if (unlikely(ret < n)) {
>>>     do {
>>>         rte_pktmbuf_free(m_table[ret]);
>>>     } while (++ret < n);
>>> }
>


Regards,
Keith

Regards,
Javier


Regards,
Keith