From: Javier Coleto Fern?ndez <javicoleto44 at gmail.com<mailto:[email protected]>> 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
