From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id C73942BA1 for ; Fri, 16 Nov 2018 10:29:37 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D8346221D0; Fri, 16 Nov 2018 04:29:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 16 Nov 2018 04:29:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=fYFvuTMzERxK15QqPHuCitnGDEu/mRw/DZREjjCcmWs=; b=jPZQ7z9JU0n4 1CqfSeW7Oow8hc/FeSrZmjGdx6vV1Df4tLPq/RxnoJBlrNO2dz/y1LDwRytGAuvW 8B/ElFtIjnL7NV8ytoRPfUG86Wii4Acvaz1R5Cj9D5eiMLv4Oy5T19szGY/A0lhq Y+RQTpsSzj34RF/ChBHnN4FXPmNwh5k= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=fYFvuTMzERxK15QqPHuCitnGDEu/mRw/DZREjjCcm Ws=; b=L4b7FaMEfTz4j8iOkfxU94rHtktaFCCx8MUj05irUmyGeKwvwwl8o15LQ IcIn0mY2fbKAZuX2Z10TUz26cTjza5oVz0c+JLDBbjkM2MTcLoWB0iFR+k01C/Lk cWyhXGqeeNDb12DpUoYa7jRgWNdGGPHDSZ9D8nrCfL1EP0RZGB+oBSQU1L6TSHwH uMxTrF6NqcISVAXxTJR0I1Y4JRcsSEY6Fv4Y5rEYD5nCzArl4ES2uk7GZD/0jhMx /doB5WpLG2E0CmdbwhXWpuAFS44oQTloHLPR13mcJspxF+HjsuF8xTawWTWjazor ixSPKkPByidv+shxrQYHyNYoxWKWQ== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D4AC102E8; Fri, 16 Nov 2018 04:29:34 -0500 (EST) From: Thomas Monjalon To: Ilya Maximets Cc: dev@dpdk.org, Ferruh Yigit , ovs-dev@openvswitch.org, Konstantin Ananyev , "Stokes, Ian" , Kevin Traynor , Ophir Munk , Shahaf Shuler , Eelco Chaudron , arybchenko@solarflare.com Date: Fri, 16 Nov 2018 10:29:32 +0100 Message-ID: <11426330.8DnILqFDIn@xps> In-Reply-To: <70d58383-da8b-4c15-a8c4-f6f853268486@samsung.com> References: <70d58383-da8b-4c15-a8c4-f6f853268486@samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Direct using of 'rte_eth_devices' in DPDK apps. 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, 16 Nov 2018 09:29:38 -0000 Hi, 16/11/2018 09:42, Ilya Maximets: > Hi, > While discussing the ways to enable DPDK 18.11 new features in OVS > there was suggestions to use 'rte_eth_devices[]' array directly. > But this array is marked as '@internal' and also it located in > the internal header 'lib/librte_ethdev/rte_ethdev_core.h' with the > following disclaimer: > > /** > * @file > * > * RTE Ethernet Device internal header. > * > * This header contains internal data types. But they are still part of the > * public API because they are used by inline functions in the published API. > * > * Applications should not use these directly. > * > */ > > From the other hand, test-pmd and some example apps in DPDK source > tree are using this array for various reasons. > > So, is it OK to use this array directly or not? Good question :) Thanks for bringing this discussion. As you said, it is public because of inline functions using it directly for performance purpose. The DPDK API is bad for separating public and internal stuff. And over time, there is not a lot of attention on trying to not use internal symbols in applications. > In general we need to change the API, i.e. make 'rte_eth_devices' part > of a public API. Or change the test-pmd and example apps to stop > using it. I agree we need to decide an option and make it clear. We can try to make this variable private and add more public functions to use it (I'm thinking at more iterators like sibling ones). It would clarify the API. It can be evaluated what is the real cost after compiler optimization for Rx/Tx functions. It can also be evaluated to uninline functions. On the other hand, we can wonder what is the real benefit of trying to hide access to internal resources. Should we make all public? > One more related question: Is it OK to access internal device > stuff using 'device' pointer obtained by 'rte_eth_dev_info'? > This looks really dangerous. It's unclear why pointers like this > exposed to user. It's a lot easier to expose pointers than doing a good API for all uses. We need to question what is really dangerous and what we want to avoid?