[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL

Hemant Agrawal hemant.agrawal at nxp.com
Sun Sep 18 11:41:55 CEST 2016



> -----Original Message-----
> From: Jan Viktorin [mailto:viktorin at rehivetech.com]

> On Sun, 18 Sep 2016 16:56:54 +0800
> Jianbo Liu <jianbo.liu at linaro.org> wrote:
> 
> > On 18 September 2016 at 15:22, Jan Viktorin <viktorin at rehivetech.com>
> wrote:
> > > On Sun, 18 Sep 2016 13:58:50 +0800
> > > Jianbo Liu <jianbo.liu at linaro.org> wrote:
> > >
> > >> On 9 September 2016 at 16:43, Shreyansh Jain <shreyansh.jain at nxp.com>
> wrote:
> > >> > Introduction:
> > >> > =============
> > >> >
> > >> > This patch set is direct derivative of Jan's original series [1],[2].
> > >> >
> > >> >  - As this deviates substantially from original series, if need be I can
> > >> >    post it as a separate patch rather than v2. Please suggest.
> > >> >  - Also, there are comments on original v1 ([4]) which are _not_
> > >> >    incorporated in this series as they refer to section no more in new
> > >> >    version.
> > >> >  - This v3 version is based on the rte_driver/device patchset v9 [10].
> > >> >    That series introduced device structures (rte_driver/rte_device)
> > >> >    generalizing devices into PCI, VDEV, XXX. For the purpose of this
> > >> >    patchset, XXX=>SOC.
> > >
> > > [...]
> > >
> > >> >
> > >> > 5) Design considerations that are different from PCI:
> > >> >  - Each driver implements its own scan and match function. PCI uses the
> BDF
> > >> >    format to read the device from sysfs, but this _may_not_ be a case for a
> > >> >    SoC ethernet device.
> > >> >    = This is an important change from initial proposal by Jan in [2]. Unlike
> > >> >    his attempt to use /sys/bus/platform, this patch relies on the
> > >> > PMD to
> > >>
> > >> It could be many redundant code if Each PMD driver has the scan
> > >> function if its own.
> > >> I think Jan's implementation is common to many platform drivers.
> > >
> > > I personally can find a use case for having a custom scan function.
> > > However, we should at least provide a default implementation.
> > > Probably, both the scan and match functions should be used to
> > > _override_ a default behaviour. So, only drivers that require to
> > > scan devices in a specific way would provide a custom function for this.
> > >
> > And for each platform/product....
> >
> > > I agree, that this can sometimes lead to code duplication. Moreover,
> > > it opens door for a very non-standard, unsecure and wrong-by-design
> > > approaches. I'd like more to provide one or more scan
> > > implementations in EAL and do not put this responsibility on PMDs.

 [Hemant]  A common/default scan function can be added, provided at least one or more  PMD driver support it. 
w.r.t Jan's original scan function, it was not suitable for any of the NXP SoC's whether ARM or PowerPC.

Unable to validate the Jan's scan function on a real platform, we have skipped it for next phase.  
Addition of a default scan function can only be done in next phase, when we find a suitable SoC PMD driver supporting it.
> > >
> > >>
> > >> >    detect the devices. This is because SoC may require specific or
> > >> >    additional info for device detection. Further, SoC may have
> > >> > embedded
> > >
> > > Can you provide an example for "additional info for device detection"?
> > >
> > >>
> > >> Can you give us more precise definition about SoC driver? Does it
> > >> include the driver in ARM server?
> > >
> > > I am sorry but I don't understand this question.
> > >
> > > What you mean by a "driver in ARM server"? Do you mean a kernel driver?
> > >
> > > There is no "SoC driver" in the text so what definition are asking for?
> > >
> > This patchset introduces rte_soc_driver, which is inheriting from rte_driver.
> > I want to know what devices can use this SoC driver/device framework.
> > Is it for the devices from ARM servers, or embedded systems of
> > different vendors?
> 
> First, this is not an ARM-specific feature. Consider any MAC connected to the
> processor via some on-chip bus. In the world of ARM, it is usually a kind of
> AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example.
> Here they provide the Quick Path bus (but I don't know the details). So, you
> cannot access such device as PCI. It is usually not possible to distinguish the bus
> type easily (Linux calls this a platform device).
> 
> So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on-
> Chip). Such devices can have a lower access latency because they are closer to
> the processor.
> 
> So, if you have a server system driver by a SoC with integrated MACs (no PCI-E
> involved), there is no way how to access them from DPDK. An rte_soc_device
> represents such devices and provides a way how to access them from DPDK.
> That is the goal...
> 
> You can have an embedded device (router, switch, monitoring device, NAT,
> firewall, anything in a "small box" with high throughput demands) that perfectly
> fits into this SoC framework because it would be usually based on some SoC
> (ARM, ARM64, ...).
> 
> > And this framework is too generalized, if we don't try to understand
> > "soc" in rte_soc_driver, we can use it for PCI devices. :)
> 
> No, you cannot use it for PCI devices, don't worry. There should be no PCI
> facilities like access to BARs :). But, I think I got your point.
> 
> It seems to be generalized because there is no real standard in this area. Any
> vendor of SoC can provide her custom on-chip bus. The original idea was to build
> on top of the platform_device from Linux which hides this information from you
> (unless there is some bus-specific DMA which we must handle in the DPDK PMD).
> 
 [Hemant] Agree with Jan's comments. 
This "SoC" term is coined to differentiate the non-PCI based  devices.  It is not specific to ARM or embedded systems. 
So, now we have two categories of device drivers, 
	- one which can be represented by standard PCI device framework; 
	- others, which does not fit into PCI devices model. 

The framework has to be generic to accommodate different types of drivers, as there is no "standard" driver model for SoCs.

> We could provide an rte_amba_device instead but there is no advantage in this.
> The amba bus is defined on the RTL level and not on the software level (no BARs,
> no device discovery). And there are other buses working in a similar way.
> 
> >
> > Thanks!
> > Jianbo
> 

Thanks
[Hemant] 
> 
> 
> --
>   Jan Viktorin                E-mail: Viktorin at RehiveTech.com
>   System Architect            Web:    www.RehiveTech.com
>   RehiveTech
>   Brno, Czech Republic


More information about the dev mailing list