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 4A5595A0A for ; Sat, 2 Jan 2016 19:45:46 +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 3pXsc955CgzqC; Sat, 2 Jan 2016 19:45:45 +0100 (CET) Date: Sat, 2 Jan 2016 19:45:40 +0100 From: Jan Viktorin To: Stephen Hemminger Message-ID: <20160102194540.1f04ce7d@jvn> In-Reply-To: <20160102100144.5e87e98b@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> 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=US-ASCII Content-Transfer-Encoding: 7bit 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:45:46 -0000 On Sat, 2 Jan 2016 10:01:44 -0800 Stephen Hemminger wrote: > On Fri, 1 Jan 2016 22:05:20 +0100 > Jan Viktorin wrote: > > > Introduce the interface to SoC device infrastructure. A SoC device > > here means a device integrated on the chip via a (simple) bus > > that lacks of auto-discovery and other properties which are common > > for PCI. A counterpart in the Linux Kernel would be a platform_device > > (but this is not necessarily 1:1 mapping). > > > > Systems without auto-discovery properties are described by a (Flat) > > Device Tree. Device Tree is usually available on embedded systems > > in /proc/device-tree. Every device has a unique path in the Device > > Tree and so it identifies every such device. This path is used > > to identify a device in rte_soc_addr. > > > > Binding of drivers to devices in the Linux Kernel is often done > > by matching the compatible entry in the Device Tree. As there is > > no standard/generic way to read information like vendor, model, etc. > > from each SoC device, we match devices by the compatible entry too. > > The rte_soc_id contains an array of compatible strings telling what > > each device is compatible with. > > > > There are no DPDK-specific OS drivers for SoC devices at the moment > > and unfortunately we cannot use the PCI-related ones as they contain > > too much PCI-specific logic. > > > > Whitelisting and blacklisting of devices is based on the Device Tree > > identifier (rte_soc_addr) to mimic the PCI behaviour. > > > > Signed-off-by: Jan Viktorin > > Yes, DPDK needs to work in embedded environments with device tree. > Would it be possible reimplement device tree parsing in user space? This is possible, I've already done a simple library for this few years ago [1]. However, I don't think it is suitable for DPDK. > Ideally with a shared code from kernel?? I have no idea what kernel code do you mean to share with... the drivers/of/*? In userspace, the device-tree is accessible via the filesystem (/proc/device-tree). So, I cannot see any overlap with the kernel code. > > On a pratical level, the new SoC support must be optional > (via DPDK config infrastructure), since most architectures won't be using it. > In most cases, it is better from usability if everything is runtime based, > but with SoC this is a platform/architecture configuration. I agree. In this RFC, it is not optional yet. On the EAL level, it's a matter of the right ifdefs and Makefile conditionals (I think) - it does not look to be an issue from my point of view. The problem will arise with the lib/* stuff as eg. librte_ether depends on pci-specific data structures very deeply. I've just finished a quick raw librte_ether extension of the SoC devices support trying to preserve API/ABI. Although, it is hopefully possible to preserve ABI (with SoC disabled), the code becomes a little bit spagetti-like... > > Do you consider this will break binary compatibility since > sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the > union inside rte_devargs are much smaller (like 32 bytes). > I had a bad feeling about this... Originally, I started with a pointer 'const char *' so it can be done that way... However, this brings compilator mad as it does not allow to cast char * -> const char * because of the strict DPDK compilation settings. I didn't find any workaround yet. I think I can make it just 'char *' for the next version of the patch set. [1] https://github.com/jviki/dtree -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic