From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2-b.wedos.net [46.28.106.45]) by dpdk.org (Postfix) with ESMTP id 90DA52BA4 for ; Sun, 18 Sep 2016 12:04:54 +0200 (CEST) Received: from jvn (dynamic-109-81-211-200.ipv4.broadband.iol.cz [109.81.211.200]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3scPlB02jgz5rD; Sun, 18 Sep 2016 12:04:53 +0200 (CEST) Date: Sun, 18 Sep 2016 12:04:52 +0200 From: Jan Viktorin To: Hemant Agrawal Cc: Jianbo Liu , Shreyansh Jain , "dev@dpdk.org" , David Marchand Message-ID: <20160918120452.29216084@jvn> In-Reply-To: References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1473410639-10367-1-git-send-email-shreyansh.jain@nxp.com> <20160918092220.062b95bf@jvn> <20160918111730.1cc74b74@jvn> Organization: RehiveTech X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 10:04:54 -0000 On Sun, 18 Sep 2016 09:41:55 +0000 Hemant Agrawal wrote: > > -----Original Message----- > > From: Jan Viktorin [mailto:viktorin@rehivetech.com] =20 >=20 [...] > > > And for each platform/product.... > > > =20 > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > > approaches. I'd like more to provide one or more scan > > > > implementations in EAL and do not put this responsibility on PMDs. = =20 >=20 Hi Hemant. > [Hemant] A common/default scan function can be added, provided at least= one or more PMD driver support it.=20 > w.r.t Jan's original scan function, it was not suitable for any of the NX= P SoC's whether ARM or PowerPC. >=20 > Unable to validate the Jan's scan function on a real platform, we have sk= ipped it for next phase. =20 > Addition of a default scan function can only be done in next phase, when = we find a suitable SoC PMD driver supporting it. Quite frankly, the situation is same for me. I still have no clue about your approach which seems to be pretty non-standard. I have no way how to test it. My approach can be tested on any Linux machine with platform devices and device-tree enabled. You would see that I detect those devices (I don't mean any certain network device, I mean all platform devices) and if you provide a driver with a proper compatible string it will be set for you. I presume that I don't have any upstreamable PMD for this at the moment. =46rom the very generic scan approach, I cannot see, what kernel infrastructure are you going to use. We should support at least the VFIO-platform which is standard and with IOMMU, it is considered secure. Any other approach would require an out-of-tree kernel driver or some non-secure access to devices. I don't say it is very wrong, but we should be careful about this. > > > > =20 > > > >> =20 > > > >> > detect the devices. This is because SoC may require specific = or > > > >> > additional info for device detection. Further, SoC may have > > > >> > embedded =20 > > > > > > > > Can you provide an example for "additional info for device detectio= n"? Can you? Regards Jan [...] --=20 Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic