From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id A82CEC30A for ; Fri, 22 May 2015 15:55:05 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 22 May 2015 06:55:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,475,1427785200"; d="scan'208";a="698896612" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.149]) by orsmga001.jf.intel.com with SMTP; 22 May 2015 06:55:02 -0700 Received: by (sSMTP sendmail emulation); Fri, 22 May 2015 14:55:01 +0025 Date: Fri, 22 May 2015 14:55:01 +0100 From: Bruce Richardson To: Shyam Sundar Govindaraj Message-ID: <20150522135501.GA4124@bricha3-MOBL3> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] DPDK LPM table thread safety X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 13:55:06 -0000 On Thu, May 21, 2015 at 05:51:34PM +0000, Shyam Sundar Govindaraj wrote: > Hi > > I am interested in DPDK LPM implementation. I understand the high performance of this LPM table but, when it comes to multithreaded application, I read the following safety issue in DPDK documentation. I understand that multithread read and multithread write are not possible without locking table. But I want to know if single thread write and multithread read are possible with your implementation without any locking mechanism. For the LPM library, I don't believe any such guarantees are made about that case. However, assuming LPM for IPv4 here, the individual LPM entries are only 16-bits in size, and, from what I see in the code, are always being assigned as a single entry, so the code may indeed by multi-reader, single-writer safe. Unfortunately, it would need a proper examination of the code to fully verify this - my quick re-reading of the code is not enough :-), and it may also depend, to some extent on the compiler used, whether the compiler converts the assignment of one 16-bit structure to another 16-bit structure as a field-by-field copy, or as a single copy of a uint16_t type. Not a very satisfactory answer, I'm afraid, but if you do look at this further, please let us know the result of your investigation. It would be good to get the rte_lpm library made/confirmed thread-safe. Regards, /Bruce > > 20. Thread Safety of DPDK Functions > "The hash and LPM libraries are, by design, thread unsafe in order to maintain performance. However, if required the developer can add layers on top of these libraries to provide thread safety. Locking is not needed in all situations, and in both the hash and LPM libraries, lookups of values can be performed in parallel in multiple threads. Adding, removing or modifying values, however, cannot be done in multiple threads without using locking when a single hash or LPM table is accessed. Another alternative to locking would be to create multiple instances of these tables allowing each thread its own copy". > http://dpdk.org/doc/guides/prog_guide/thread_safety_intel_dpdk_functions.html > > Thanks > Shyam