[dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface

[Jan Viktorin]

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