From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 72CEB1B787 for ; Fri, 11 May 2018 00:13:32 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E457720EC5; Thu, 10 May 2018 18:13:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 10 May 2018 18:13:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=o1ELFfI4Icu7igqeBlQ2azE6pu lwyK89cPDUuiAqEc4=; b=RdIUJBqy27vdsH3rETuTXgpzMpFYHLJn+Wi/pKOn5U adiLKyylcSKRzcKeV42PdqeTzrBwV3DCYygmxii8rBbD3mniVUH6QZ6A5J1bsBtF u8kzrMv/nEfHKCN/1QeIyx++A12xxgzmfEXQaHD9zAA0mGkGlyXL8qxzZuQa0JPm 8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=o1ELFf I4Icu7igqeBlQ2azE6pulwyK89cPDUuiAqEc4=; b=lpag6r/b+0dW0I8FutsepE R7pRIbhk9nD1vWOIZlpmM6Mgv2bpPLLPiYWQx/lvkYABnKR+b85eEC+hyYKqrMFR uDLkMEByVu2TsAVkfs4juBzjwL8T6N0btqR7PYQTQX40L83lHccmZiRI4siPLvQK wYKXuHmhQB6D2wVckla4KY9MFkodgK65jP9os00cOSedQpKGVotOeihLh8jUlEyk dMr7uQ7/vakdGDBtKHvM2RXjaa+cFtK0hmnjICWv8hGrR0E9MRqWkTA+KWzL4mCT VuzBT463a2DP5WsANsUHT7b2O2d6PShAcKCqMFOZip2P9b97X59KUX2S7IyMbTsQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3852DE43E8; Thu, 10 May 2018 18:13:30 -0400 (EDT) From: Thomas Monjalon To: Stephen Hemminger Cc: =?ISO-8859-1?Q?Ga=EBtan?= Rivet , dev@dpdk.org, Matan Azrad Date: Fri, 11 May 2018 00:13:29 +0200 Message-ID: <8877388.Xvcb3uZcyi@xps> In-Reply-To: <20180510133516.6552e936@xeon-e3> References: <20180509094337.26112-1-thomas@monjalon.net> <20180509122116.ljistjpz3dfljdqo@bidouze.vm.6wind.com> <20180510133516.6552e936@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH 07/11] ethdev: add lock to port allocation check 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: Thu, 10 May 2018 22:13:32 -0000 10/05/2018 22:35, Stephen Hemminger: > On Wed, 9 May 2018 14:21:17 +0200 > Ga=EBtan Rivet wrote: >=20 > > A suggestion about the naming here. > > Reading subsequent patches, we can see this function being used during > > ethdev allocation routines. The _lock_free suffix is a little > > misleading, as for an instant one can think that there is something > > being freed about an allocated ethdev lock. > >=20 > > I would suggest > >=20 > > * rte_eth_dev_allocated_nolock > > or > > * rte_eth_dev_allocated_lockless > > (or even rte_eth_lockless_dev_allocated) > >=20 > > instead. >=20 > Personally, used to the convention of: > rte_eth_dev_find(name) > and > _rte_eth_dev_find(name) >=20 > The _ implies internal version without lock. It is a matter of taste. We have chosen "nolock" in v2, and I think it is explicit. > Also allocated to me implies a boolean test only. Yes, the name is a bit strange. But it is old and out of the scope of this patch. If we want to change it, it is an API deprecation.