Re: [dpdk-dev] [PATCH v7 11/21] eal/soc: implement probing of drivers

[Thomas Monjalon <thomas.monjalon@6wind.com>]

2016-11-10 14:40, Shreyansh Jain:
> On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote:
> > On 10 November 2016 at 14:10, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> >> On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote:
> >>> I'm still not sure about the purpose of soc_scan, and how to use it.
> >>
> >>
> >> For each device to be used by DPDK, which cannot be scanned/identified using
> >> the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way
> >> for driver to make those devices part of device lists.
> >>
> >> Ideally, 'scan' is not a function of a driver. It is a bus function - which
> >> is missing in this case.
> >>
> >>> If it's for each driver, it should at least struct rte_soc_driver * as
> >>> its parameter.
> >>
> >>
> >> Its for each driver - assuming that each non-PCI driver which implements it
> >> knows how to find devices which it can control (for example, special area in
> >> sysfs, or even platform bus).
> >>
> >
> > Considering there are several drivers in a platform bus, each driver
> > call the scan function, like the rte_eal_soc_scan_platform_bus() you
> > implemented.
> > The first will add soc devices to the list, but the remaining calls
> > are redundant.
> 
> Indeed. This is exactly the issue we will face if we try and move this 
> scan/match logic to PCI - all devices are identified in one step.
> 
> There is a difference in principle here:
> A SoC device/driver combination is essentially focused towards a single 
> type of bus<->devices. For example, a NXP PMD would implement a scan 
> function which would scan for all devices on NXP's bus. This would not 
> conflict with another XYZ SoC PMD which scans its specific bus.
> 
> There is caveat to this - the platform bus. There can be multiple 
> drivers which can serve platform bus compliant devices. First 
> PMD->scan() initiated for such a bus/device would leave all other scans 
> redundant.
> 
> More similar caveats will come if we consider somewhat generic buses. At 
> least I couldn't find any interest for such devices in the ML when I 
> picked this series (from where Jan left it).
> 
> Probably when more common type of PMDs come in, some default scan 
> implementation can check for skipping those devices which are already 
> added. It would be redundant but harmless.

If several drivers use the same bus, it means the bus is standard enough
to be implemented in EAL. So the scan function of this bus should be
called only once when calling the generic EAL scan function.