[dpdk-dev] Mbuf leak issue with IXGBE in vector mod
Ori Zakin
ori at drivenets.com
Mon Aug 8 11:45:32 CEST 2016
Hi,
1. I’m seeing 128 mbufs leaked on each stop/start cycle when polling is stopped, you’re right that the leak is more severe when the device is polled while calling rte_eh_dev_stop.
2. Maybe the limitations per each function should be moved in the rte_eh_dev documentation from the header to each of the functions so that they’re more accessible when using a specific function.
Thanks,
Ori
On 5 Aug 2016, at 4:00 AM, Lu, Wenzhuo <wenzhuo.lu at intel.com<mailto:wenzhuo.lu at intel.com>> wrote:
Hi Ori,
-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ori Zakin
Sent: Thursday, August 4, 2016 11:38 PM
To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org<mailto:dev at dpdk.org>
Subject: [dpdk-dev] Mbuf leak issue with IXGBE in vector mod
Hi,
1. When calling rte_eth_dev_stop mbuf pool is depleted.
There appears to be a race condition that occurs when RTE_IXGBE_INC_VECTOR
is defined:
ixgbe_reset_rx_queue(struct ixgbe_adapter *adapter, struct ixgbe_rx_queue
*rxq) { …….
#ifdef RTE_IXGBE_INC_VECTOR
rxq->rxrearm_start = 0;
sleep here appears to solve
rxq->rxrearm_nb = 0;
#endif
Behaviour also described here:
http://dpdk.org/ml/archives/users/2016-April/000488.html
2. Steps to recreate issue:
* rte_mempool_free_count
* rte_eth_dev_stop
* rte_mempool_free_count - should see a spike in allocated mbufs from
mempool.
Have you stopped the rx/tx before do this stop/start? I think we'll hit this memory leak problem if the traffic is not stopped. There's an assumption that it’s APP's responsibility to stop rx/tx before operating the ports as we know dpdk is lockless.
3. 2 workarounds that appear to work:
* Set CONFIG_RTE_IXGBE_INC_VECTOR=n.
* Add sleep in ixgbe_reset_rx_queue
Regards.
Ori Zakin
More information about the dev
mailing list