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

Stephen Hemminger stephen at networkplumber.org
Sat Jan 2 20:14:03 CET 2016


On Sat, 2 Jan 2016 19:52:16 +0100
Jan Viktorin <viktorin at rehivetech.com> wrote:

> On Sat, 2 Jan 2016 18:35:08 +0000
> "Wiles, Keith" <keith.wiles at intel.com> 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??  
> > 
> > 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.
> 
> 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 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.
> 
> This is a matter of preserving ABI. Turning PCI-support to be optional
> seems to be a difficult step at the moment.
> 
> > 
> > Can we detect somehow we are on a system with SoC support or even a system 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?
> 

I am just as concerned with building and having useless code.
For now most environments can just use PCI, and having to carry around
dead code seems wasteful and potential for some security abuse as well.


More information about the dev mailing list