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

[Wiles, Keith]

On 1/2/16, 12:01 PM, "dev on behalf of Stephen Hemminger" <dev-bounces at dpdk.org on behalf of 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>

I do like the idea of having a clean way to locate SoC devices and this design looks very clean to me with a brief read. Thanks Jan.
>
>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??

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.
>
>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 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 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’ed in the code. Plus adding more ifdefs is not a good testing solution.

Can we detect somehow we are on a system with SoC support or even a system that supports PCI for that matter?
>
>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).
>
>


Regards,
Keith