>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> 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. 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>:
>>>
>>> On Mon, Apr 18, 2016 at 5:34 PM, Javier Coleto Fern?ndez
>>> <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
