From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [RFC 1/7] eal/common: define rte_soc_* related common interface Date: Sat, 2 Jan 2016 11:14:03 -0800 Message-ID: <20160102111403.1389b983@xeon-e3> References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1451682326-5834-2-git-send-email-viktorin@rehivetech.com> <20160102100144.5e87e98b@xeon-e3> <0CC8CFBE-CFA0-4BCA-B09D-6287801C406F@intel.com> <20160102195216.4b660495@jvn> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Jan Viktorin Return-path: Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by dpdk.org (Postfix) with ESMTP id A5EF15A0A for ; Sat, 2 Jan 2016 20:13:57 +0100 (CET) Received: by mail-pa0-f42.google.com with SMTP id do7so538504pab.2 for ; Sat, 02 Jan 2016 11:13:57 -0800 (PST) In-Reply-To: <20160102195216.4b660495@jvn> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Sat, 2 Jan 2016 19:52:16 +0100 Jan Viktorin wrote: > On Sat, 2 Jan 2016 18:35:08 +0000 > "Wiles, Keith" wrote: >=20 > > >Yes, DPDK needs to work in embedded environments with device tree. > > >Would it be possible reimplement device tree parsing in user space? > > >Ideally with a shared code from kernel?? =20 > >=20 > > Stephen, Do you mean we have to add kernel code to support DPDK on SoC = Platforms? If that is the case I would like to not require code be added to= the kernel to support DPDK. >=20 > We will need a kernel module. But this is not necessarily related to the > device-tree parsing. >=20 > > > > > >On a pratical level, the new SoC support must be optional > > >(via DPDK config infrastructure), since most architectures won't be us= ing it. > > >In most cases, it is better from usability if everything is runtime ba= sed, > > >but with SoC this is a platform/architecture configuration. =20 > >=20 > > I am not sure I agree with the optional support, as it could be stated = that PCI support is optional on SoC platforms. It would be best to not trea= t SoC support as special compared to PCI support. Other then extra footprin= t it does not seem reasonable to require SoC support to be ifdef=E2=80=99ed= in the code. Plus adding more ifdefs is not a good testing solution. >=20 > This is a matter of preserving ABI. Turning PCI-support to be optional > seems to be a difficult step at the moment. >=20 > >=20 > > Can we detect somehow we are on a system with SoC support or even a sys= tem that supports PCI for that matter? >=20 > IMO, we can detect two things: "PCI is present on the system" and > "Device tree is accessible in /proc/device-tree". Is this acceptable? >=20 I am just as concerned with building and having useless code. For now most environments can just use PCI, and having to carry around dead code seems wasteful and potential for some security abuse as well.