From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 04D2A5A0A for ; Sat, 2 Jan 2016 19:52:22 +0100 (CET) Received: from jvn (dynamic-109-81-211-160.ipv4.broadband.iol.cz [109.81.211.160]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3pXsln4zpmzYb; Sat, 2 Jan 2016 19:52:21 +0100 (CET) Date: Sat, 2 Jan 2016 19:52:16 +0100 From: Jan Viktorin To: "Wiles, Keith" Message-ID: <20160102195216.4b660495@jvn> In-Reply-To: <0CC8CFBE-CFA0-4BCA-B09D-6287801C406F@intel.com> 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> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface 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: Sat, 02 Jan 2016 18:52:22 -0000 On Sat, 2 Jan 2016 18:35:08 +0000 "Wiles, Keith" wrote: > >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 Pl= atforms? If that is the case I would like to not require code be added to t= he kernel to support DPDK. We will need a kernel module. But this is not necessarily related to the device-tree parsing. > > > >On a pratical level, the new SoC support must be optional > >(via DPDK config infrastructure), since most architectures won't be usin= g it. > >In most cases, it is better from usability if everything is runtime base= d, > >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 th= at PCI support is optional on SoC platforms. It would be best to not treat = SoC support as special compared to PCI support. Other then extra footprint = it does not seem reasonable to require SoC support to be ifdef=E2=80=99ed i= n the code. Plus adding more ifdefs is not a good testing solution. This is a matter of preserving ABI. Turning PCI-support to be optional seems to be a difficult step at the moment. >=20 > Can we detect somehow we are on a system with SoC support or even a syste= m that supports PCI for that matter? 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 Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic