From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 069942BB1 for ; Fri, 16 Nov 2018 10:51:21 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2018 01:51:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,239,1539673200"; d="scan'208";a="109080921" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga002.jf.intel.com with ESMTP; 16 Nov 2018 01:51:18 -0800 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.8]) by IRSMSX107.ger.corp.intel.com ([169.254.10.79]) with mapi id 14.03.0415.000; Fri, 16 Nov 2018 09:51:16 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon , Ilya Maximets CC: "dev@dpdk.org" , "Yigit, Ferruh" , "ovs-dev@openvswitch.org" , "Stokes, Ian" , Kevin Traynor , Ophir Munk , Shahaf Shuler , Eelco Chaudron , "arybchenko@solarflare.com" Thread-Topic: Direct using of 'rte_eth_devices' in DPDK apps. Thread-Index: AQHUfYhZNAJRmD+zC0KV6rHk7OQB16VSIrEAgAADDZA= Date: Fri, 16 Nov 2018 09:51:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258010CEB8C73@IRSMSX106.ger.corp.intel.com> References: <70d58383-da8b-4c15-a8c4-f6f853268486@samsung.com> <11426330.8DnILqFDIn@xps> In-Reply-To: <11426330.8DnILqFDIn@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTUzMmY1YTEtNGNhYS00NzE3LWI4MzUtZjY4ZWFkZWRiMDQ2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiN09mZ2tkOVBLV1BYTks1dWs1VkUrNjhcL1BFNlhoTWQyOVdOUFVmWllzejFWZElDMzFoQlwvdjVPalBFdTVEa3ZXIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:51:22 -0000 Hi everyone, >=20 > Hi, >=20 > 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 publishe= d 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? >=20 > Good question :) > Thanks for bringing this discussion. >=20 > 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. >=20 > > 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. >=20 > I agree we need to decide an option and make it clear. >=20 > 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. >=20 > 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? In that case every change in any of such structures will be an ABI breakage= . Even now any change in rte_eth_dev is quite problematic because of that. I think we better keep them private as much as possible and cleanup our examples and testpmd code. Konstantin >=20 > > 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. >=20 > 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? >=20 >=20