From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: A question about the possible race condition in the l3fwd example? Date: Mon, 27 Nov 2017 20:06:13 -0800 Message-ID: <20171127200613.74783eff@xeon-e3> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "users@dpdk.org" , "dev@dpdk.org" To: "Wu, Xiaoban" Return-path: Received: from mail-pg0-f68.google.com (mail-pg0-f68.google.com [74.125.83.68]) by dpdk.org (Postfix) with ESMTP id F3F2216E for ; Tue, 28 Nov 2017 05:06:21 +0100 (CET) Received: by mail-pg0-f68.google.com with SMTP id j16so19709824pgn.9 for ; Mon, 27 Nov 2017 20:06:21 -0800 (PST) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 28 Nov 2017 02:22:57 +0000 "Wu, Xiaoban" wrote: > Dear All, > > > I am studying the source code of the l3fwd example. I am confused about a possible race condition in the l3fwd_lpm_simple_forward(). > > > In this function it calls send_single_packet(), which executes the following code, > > len = qconf->tx_mbufs[port].len; > qconf->tx_mbufs[port].m_table[len] = m; > len++; > > As you can see, if two threads are trying to call send_single_packet() at the same time and send different packets to the same port, which writes the value to the same array and updates the same counter 'len', then the race condition happens, so we might lose packets. > > Can anybody please clarify if this indeed brings race condition? If yes, then why we want to design it in this way, just for high performance? If no, why? > > Thanks very much for your help. > > Best wishes, > Xiaoban > > > qconf is in in a per core data structure, so it is impossible for sharing to happen.