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 03C581B310 for ; Mon, 23 Oct 2017 10:44:34 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2017 01:44:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,422,1503385200"; d="scan'208";a="1234034650" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 23 Oct 2017 01:44:32 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 23 Oct 2017 09:44:32 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.167]) by irsmsx111.ger.corp.intel.com ([169.254.2.30]) with mapi id 14.03.0319.002; Mon, 23 Oct 2017 09:44:31 +0100 From: "De Lara Guarch, Pablo" To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= , "Doherty, Declan" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 00/14] Move PCI away from the EAL Thread-Index: AQHTMGEL8or1Oqz+l0a4+TGUW7LTg6LexmKAgAADjYCAEon+8A== Date: Mon, 23 Oct 2017 08:44:31 +0000 Message-ID: References: <98afeb56-69b4-dcff-df5b-897d279c5072@intel.com> <20171011143213.GF31685@bidouze.vm.6wind.com> In-Reply-To: <20171011143213.GF31685@bidouze.vm.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTE0NDYwOGMtMmM2Yi00YzZiLTk1NTAtYjRlZTAzZWJhNjUxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6InpXeUZBOTV4SU85WE9EYlBWSDJYNnVXcHc3RnBNazNmMk5hT01xbDhSV009In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 00/14] Move PCI away from the EAL 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: Mon, 23 Oct 2017 08:44:35 -0000 Hi Gaetan, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ga=EBtan Rivet > Sent: Wednesday, October 11, 2017 3:32 PM > To: Doherty, Declan > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 00/14] Move PCI away from the EAL >=20 > On Wed, Oct 11, 2017 at 03:19:31PM +0100, Doherty, Declan wrote: > > On 18/09/2017 10:31 AM, Gaetan Rivet wrote: > > >Hi all, > > > > > >Here is a new version of the PCI bus move out of the EAL. > > > > > >The EAL PCI implementation is divided in two parts: > > > > > > - librte_pci: library offering helpers to handle PCI objects > > > - librte_bus_pci: bus driver for PCI devices > > > > > >This allows other libraries / tools to use PCI elements (location, > > >mappings, parsing operations, etc) without forcing a dependency on a > bus driver. > > > > > >The latter should not have to export helpers that others might need. > > >It is focused on defining the rte_pci_device, rte_pci_driver objects > > >and their handling. > > > > > >The cryptodev library has hard dependencies on rte_pci_devices (used > > >by generic probe function). Other similar libs (ether and eventdev) > > >avoided the issue by inlining such functions and expecting users to > > >include the relevant headers once the PCI bus has already been built. > > > > > >@Declan: > > >I proposed a solution that would avoid inlining those functions, > > >which does not feel right. Let me know what you think of it or if you > > >think of a better solution. I think it would be best to have > > >cryptodev completely independent from PCI / vdev as far as the lib in > > >concerned (the vdev bus will move as well). > > > > > > > > > Hey Gaetan, apologies for the delay in getting back to you on this, I > > had been looking at this but got sidelined onto other issues before > > usersapce and I'm only getting back to it now. I think that while your > > solution works it just highlights the dependency which probably > > shouldn't be there between the cryptodev library and PCI devices. I've > > had a look, and the functions in the cryptodev which you moved don't > > really provide that much useful functionality. I done some testing and > > completely removed them and just update the QAT PMD which is the only > > crypto PMD which was using them and it seems much cleaner to me. I'll > > push a patch for this change later today and it will allow you to drop > > the patch "cryptodev: move PCI specific helpers to drivers/crypto" from > this set. > > > > Regards > > Declan > > > > > > >=20 > Hi Declan, >=20 > All right, seems good from my PoV. I will rebase onto your patch once it = is > sent. >=20 Could you take a look at Declan's patchset and tell him what you think? http://dpdk.org/ml/archives/dev/2017-October/079827.html It might be a bit late, but if we think it is a better approach for cryptod= ev, we could avoid creating a new PCI folder under drivers/crypto. Thanks! Pablo