On Sat, 2 Jan 2016 10:01:44 -0800 Stephen Hemminger <stephen at networkplumber.org> wrote:
> On Fri, 1 Jan 2016 22:05:20 +0100 > Jan Viktorin <viktorin at rehivetech.com> 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 <viktorin at rehivetech.com> > > 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 at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic