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

Shreyansh Jain shreyansh.jain at nxp.com
Fri Nov 11 07:04:03 CET 2016


On Thursday 10 November 2016 02:56 PM, Thomas Monjalon wrote:
> 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 at 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.
>

In the current model, without a bus like object, this can only be 
implemented as a hack. This is because:
- If each driver has its scan, some of them (those on a common bus) 
would have their scan nullified
- Then, EAL would initiate the scan on their behalf. (rte_eal_init)
- Whereas, for those drivers which are 'special' scan, EAL would have to 
call each driver's scan.
- This selection is manual code change (nullifying the scan function).
- And then, EAL would have various 'generic' scan's chained together 
other than driver->scan().

A cleaner model would have been that EAL always calls the drivers->scan().

Obviously, this issue vanishes as soon as we have the bus->scan() like 
implementation where a bus would represent multiple devices/drivers.

_________
Shreyansh


More information about the dev mailing list