From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 85D2458D6
 for <dev@dpdk.org>; Fri, 20 Dec 2013 22:24:33 +0100 (CET)
Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]
 helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa
 (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80)
 (envelope-from <olivier.matz@6wind.com>)
 id 1Vu7aB-0006d5-2j; Fri, 20 Dec 2013 22:26:09 +0100
Message-ID: <52B4B662.8050400@6wind.com>
Date: Fri, 20 Dec 2013 22:28:02 +0100
From: Olivier MATZ <olivier.matz@6wind.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: Peter Chen <peter.feifan.chen@gmail.com>
References: <CAG9qd2pi-Q7LawBymDSsAY3054FUqf7RK0L61oDrsKVY_Q4S0Q@mail.gmail.com>
 <201312191804.31322.thomas.monjalon@6wind.com>
 <CAMGYKAfuRdhuydXixJ-ycTQcksRqSKOmFpz8fJGuNZEob04E6Q@mail.gmail.com>
In-Reply-To: <CAMGYKAfuRdhuydXixJ-ycTQcksRqSKOmFpz8fJGuNZEob04E6Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Is rte_mempool library is multi-thread safe ???
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Dec 2013 21:24:33 -0000

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