From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id BEA571B517 for ; Fri, 5 Apr 2019 16:28:33 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 07:28:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,312,1549958400"; d="scan'208";a="313433284" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga005.jf.intel.com with SMTP; 05 Apr 2019 07:28:30 -0700 Received: by (sSMTP sendmail emulation); Fri, 05 Apr 2019 15:28:30 +0100 Date: Fri, 5 Apr 2019 15:28:29 +0100 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: dev@dpdk.org Message-ID: <20190405142829.GA1710@bricha3-MOBL.ger.corp.intel.com> References: <20190405134542.28618-1-mattias.ronnblom@ericsson.com> <7428acf8-fd06-fcc5-521b-37ee0fa1729a@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7428acf8-fd06-fcc5-521b-37ee0fa1729a@ericsson.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 14:28:34 -0000 On Fri, Apr 05, 2019 at 03:51:39PM +0200, Mattias Rönnblom wrote: > On 2019-04-05 15:45, Mattias Rönnblom wrote: > > The rte_rand() documentation left it unspecified if the rte_rand() was > > multi-thread safe or not, and the implementation (based on lrand48()) > > was not. > > > > This commit makes rte_rand() safe to use from any lcore thread by > > using lrand48_r() and per-lcore random state structs. Besides the > > obvious improvement in terms of correctness (for concurrent users), > > this also much improves rte_rand() performance, since the threads no > > longer shares state. For the single-threaded case, this patch causes > > ~10% rte_rand() performance degradation. > > > > It's a little unclear to me, if lrand48_r() exists in FreeBSD or not. Could > someone confirm? > Nothing shows up for me in the man pages for such a function on FreeBSD 12, so I suspect they aren't available. > Another question I have is in which section of the version.map file the new > symbols should go. Experimental, or 19.05? > I think it should be 19.05. Since the APIs have been around as inline functions for some time now, I don't see the point of having them be experimental for a time. > The source interface is backward compatible, but the functions are no longer > inline functions in the header file, and thus needs to go somewhere to be > properly exported. Regards, /Bruce From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id BEE1CA0679 for ; Fri, 5 Apr 2019 16:28:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7089D1B51A; Fri, 5 Apr 2019 16:28:35 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id BEA571B517 for ; Fri, 5 Apr 2019 16:28:33 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 07:28:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,312,1549958400"; d="scan'208";a="313433284" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35]) by orsmga005.jf.intel.com with SMTP; 05 Apr 2019 07:28:30 -0700 Received: by (sSMTP sendmail emulation); Fri, 05 Apr 2019 15:28:30 +0100 Date: Fri, 5 Apr 2019 15:28:29 +0100 From: Bruce Richardson To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: dev@dpdk.org Message-ID: <20190405142829.GA1710@bricha3-MOBL.ger.corp.intel.com> References: <20190405134542.28618-1-mattias.ronnblom@ericsson.com> <7428acf8-fd06-fcc5-521b-37ee0fa1729a@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7428acf8-fd06-fcc5-521b-37ee0fa1729a@ericsson.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190405142829.5wxXOXE8UAj8BZ4BoJN73Fi0pUmNw5Ekuu2N-4JY3Fo@z> On Fri, Apr 05, 2019 at 03:51:39PM +0200, Mattias Rönnblom wrote: > On 2019-04-05 15:45, Mattias Rönnblom wrote: > > The rte_rand() documentation left it unspecified if the rte_rand() was > > multi-thread safe or not, and the implementation (based on lrand48()) > > was not. > > > > This commit makes rte_rand() safe to use from any lcore thread by > > using lrand48_r() and per-lcore random state structs. Besides the > > obvious improvement in terms of correctness (for concurrent users), > > this also much improves rte_rand() performance, since the threads no > > longer shares state. For the single-threaded case, this patch causes > > ~10% rte_rand() performance degradation. > > > > It's a little unclear to me, if lrand48_r() exists in FreeBSD or not. Could > someone confirm? > Nothing shows up for me in the man pages for such a function on FreeBSD 12, so I suspect they aren't available. > Another question I have is in which section of the version.map file the new > symbols should go. Experimental, or 19.05? > I think it should be 19.05. Since the APIs have been around as inline functions for some time now, I don't see the point of having them be experimental for a time. > The source interface is backward compatible, but the functions are no longer > inline functions in the header file, and thus needs to go somewhere to be > properly exported. Regards, /Bruce