From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailfilter01.viettel.com.vn (mailfilter01.viettel.com.vn [125.235.240.53]) by dpdk.org (Postfix) with ESMTP id D76721E865 for ; Mon, 11 Jun 2018 11:42:13 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.49,501,1520874000"; d="scan'208";a="78212101" Received: from 125.235.240.44.adsl.viettel.vn (HELO mta1.viettel.com.vn) ([125.235.240.44]) by mailfilter01.viettel.com.vn with ESMTP; 11 Jun 2018 16:42:11 +0700 Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 2DAD4610123; Mon, 11 Jun 2018 16:41:59 +0700 (ICT) Received: from mta1.viettel.com.vn ([127.0.0.1]) by localhost (mta1.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id MQ_ypd1KY_rg; Mon, 11 Jun 2018 16:41:59 +0700 (ICT) Received: from localhost (localhost [127.0.0.1]) by mta1.viettel.com.vn (Postfix) with ESMTP id 0BD916100AF; Mon, 11 Jun 2018 16:41:59 +0700 (ICT) X-Virus-Scanned: amavisd-new at Received: from mta1.viettel.com.vn ([127.0.0.1]) by localhost (mta1.viettel.com.vn [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NOgfDMhSF343; Mon, 11 Jun 2018 16:41:58 +0700 (ICT) Received: from ANMLONGTB5 (unknown [27.68.241.28]) by mta1.viettel.com.vn (Postfix) with ESMTPSA id B876D61012B; Mon, 11 Jun 2018 16:41:58 +0700 (ICT) To: , Cc: "'Gobriel, Sameh'" , "'Tai, Charlie'" , "'Wang, Ren'" References: <012701d3f978$57d75d40$078617c0$@viettel.com.vn> In-Reply-To: Message-ID: <003c01d40169$4a0c7030$de255090$@viettel.com.vn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEmgUfPgj5mP2JHI2w/1N1lCqv4GgELsw/Apa1umVA= Content-Language: en-us MilterAction: FORWARD Date: Mon, 11 Jun 2018 16:41:59 +0700 (ICT) From: longtb5@viettel.com.vn Subject: Re: [dpdk-users] Membership library thread safety X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 09:42:14 -0000 Hi, My use case is pretty simple. I have two NICs and with separated lcores (different threads) handling traffic for each. Incoming packets could hit either of those separated datapath (I have not yet implemented any kind of session persistence e.g., IP hash). I want to monitor the number of active flows that are passing through my application, so for each datapath I use one setsum to keep track of new flows. The problem is that a "new" packet on one NIC may actually belong to an already existed flow that hit the other NIC first. My initial thought is to share one setsum between the two paths and that was the reason the my first email. For completeness, I use vBF with only one setsum. Currently I just treat each datapath separately, completely ignore the fact that they run in the same app, which is good enough for me atm. But for future use cases a more thorough solution is always welcomed. Best regards, -BL > -----Original Message----- > From: yipeng1.wang@intel.com [mailto:yipeng1.wang@intel.com] > Sent: Saturday, June 2, 2018 5:17 AM > To: longtb5@viettel.com.vn; users@dpdk.org > Cc: Gobriel, Sameh ; Tai, Charlie > ; Wang, Ren > Subject: RE: Membership library thread safety > > Hi, > > You are right that It is similar to other rte data structure that you can initialize > it in a master thread and do lookup in other threads. > > w.r.t. concurrency, the original plan is to have the fastest data structure used > mostly per-thread basis so any locking/atomicity guarantee is too costly. > > So for non-cache mode HT based setsum, since deletion is supported and > false-negative is not supposed to happen, I would say it only supports single > writer/delete thread. For read-write concurrency, due to the "cuckoo hash" > algorithm, there might be a short window (very unlikely) that a key lookup > could return an intermediate result while another thread writing to the table. > Depending on how your application could tolerate such case, you may or may > not want to use it for read-write concurrency. One option is to turn off the > cuckoo algorithm if you would like to play with the code a little bit. > > Vector BF also only supports single writer if you don't want false negative, > but read-write concurrency should be fine > > For cache mode HT based setsum, things are less restrictive. Since it is > supposed to be used as a cache and both false-negative and false-positive > are allowed, it would be fine for multiple writer writing concurrently. > > Note that you can always use multiple readers concurrently. > > If possible, may I ask for the use case you have? The purpose is to make the > library more usable. Feel free to propose new patches as well. If concurrency > is definitely a requirement, we could collaborate on new concurrency APIs. > We will improve the documentation as well to state things more clearly. > > Thanks > Yipeng > > >-----Original Message----- > >From: longtb5@viettel.com.vn [mailto:longtb5@viettel.com.vn] > >Sent: Friday, June 1, 2018 12:10 AM > >To: users@dpdk.org > >Cc: Wang, Yipeng1 ; Gobriel, Sameh > > > >Subject: Membership library thread safety > > > >Hi, > > > >I'm using rte_member in my application. I have two questions. > >1. Could a rte_member_setsum be initialized on one thread and used on > >another thread? > >2. Are the operations (lookup, add, reset,.) atomic, or do I need to > >use some kind of locking (e.g. rte_spinlock)? > > > >I couldn't find anything in the doc. My guess is that you can init and > >use a setsum on different threads just fine, but sharing a setsum among > >different threads does require locking. > > > >Thanks and best regards, > >-BL > >