From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: Is rte_mempool library is multi-thread safe ??? Date: Fri, 20 Dec 2013 22:28:02 +0100 Message-ID: <52B4B662.8050400@6wind.com> References: <201312191804.31322.thomas.monjalon@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Peter Chen Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Peter, On 12/19/2013 10:30 PM, Peter Chen wrote: > does that mean that on the same core, we can't do rte_eth_rx_burst in one > thread (I assume this function allocates from mempool for storing mbufs > everytime it receives a packet), while another thread calls > rte_pktmbuf_alloc from the same mem_pool? That's correct. In the rte_mempool code, there is a per-lcore cache: see the local_cache field of struct rte_mempool. If you are running several pthreads per lcore, they will share the same cache if they have the same lcore_id and the mempool is not designed for that. Therefore it can return wrong results. The cache can be disabled (at run-time or compile-time), but you will loose a lot of performance. Even if you solve the problem of the cache, as the mempool uses a ring internally, you would still experiment performance issues (see links from Thomas' previous email). By the way, why would you need to have several pthreads on one lcore? Regards, Olivier