Re: [PATCH v7 00/21] Introduce SoC device/driver framework for EAL

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

Hi Shreyansh,

I realize that we had a lot of off-list discussions on this topic
and there was no public explanation of the status of this series.

2016-10-28 17:56, Shreyansh Jain:
[...]
> As of now EAL is primarly focused on PCI initialization/probing.

Right. DPDK was PCI centric.
We must give PCI its right role: a bus as other ones.
A first step was done in 16.11 (thanks to you Shreyansh, Jan and David)
to have a better device model.
The next step is to rework the bus abstraction.

It seems a bus can be defined with the properties scan/match/notify,
leading to initialize the devices.

More comments below your technical presentation.

[...]
> This patchset introduces SoC framework which would enable SoC drivers and
> drivers to be plugged into EAL, very similar to how PCI drivers/devices are
> done today.
> 
> This is a stripped down version of PCI framework which allows the SoC PMDs
> to implement their own routines for detecting devices and linking devices to
> drivers.
> 
> 1) Changes to EAL
>  rte_eal_init()
>   |- rte_eal_pci_init(): Find PCI devices from sysfs
>   |- rte_eal_soc_init(): Calls PMDs->scan_fn
>   |- ...
>   |- rte_eal_memzone_init()
>   |- ...
>   |- rte_eal_pci_probe(): Driver<=>Device initialization, PMD->devinit()
>   `- rte_eal_soc_probe(): Calls PMDs->match_fn and PMDs->devinit();
> 
> 2) New device/driver structures:
>   - rte_soc_driver (inheriting rte_driver)
>   - rte_soc_device (inheriting rte_device)
>   - rte_eth_dev and eth_driver embedded rte_soc_device and rte_soc_driver,
>     respectively.
> 
> 3) The SoC PMDs need to:
>  - define rte_soc_driver with necessary scan and match callbacks
>  - Register themselves using DRIVER_REGISTER_SOC()
>  - Implement respective bus scanning in the scan callbacks to add necessary
>    devices to SoC device list
>  - Implement necessary eth_dev_init/uninint for ethernet instances

These callbacks are not specific to a SoC.
By the way a SoC defines nothing specific. You are using the SoC word
as an equivalent of non-PCI.
We must have a bus abstraction like the one you are defining for the SoC
but it must be generic and defined on top of PCI, so we can plug any
bus in it: PCI, vdev (as a software bus), any other well-defined bus,
and some driver-specific bus which can be implemented directly in the
driver (the NXP case AFAIK).

> 4) Design considerations that are same as PCI:
>  - SoC initialization is being done through rte_eal_init(), just after PCI
>    initialization is done.
>  - As in case of PCI, probe is done after rte_eal_pci_probe() to link the
>    devices detected with the drivers registered.
>  - Device attach/detach functions are available and have been designed on
>    the lines of PCI framework.
>  - PMDs register using DRIVER_REGISTER_SOC, very similar to
>    DRIVER_REGISTER_PCI for PCI devices.
>  - Linked list of SoC driver and devices exists independent of the other
>    driver/device list, but inheriting rte_driver/rte_driver, these are
>    also part of a global list.
> 
> 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 detect the devices. This is because SoC may require specific or
>    additional info for device detection. Further, SoC may have embedded
>    devices/MACs which require initialization which cannot be covered
>    through sysfs parsing.
>    `-> Point (6) below is a side note to above.
>    = PCI based PMDs rely on EAL's capability to detect devices. This
>    proposal puts the onus on PMD to detect devices, add to soc_device_list
>    and wait for Probe. Matching, of device<=>driver is again PMD's
>    callback.

These PCI considerations can be described as a PCI bus implementation in EAL.

> 6) Adding default scan and match helpers for PMDs
>  - The design warrrants the PMDs implement their own scan of devices
>    on bus, and match routines for probe implementation.
>    This patch introduces helpers which can be used by PMDs for scan of
>    the platform bus and matching devices against the compatible string
>    extracted from the scan.
>  - Intention is to make it easier to integrate known SoC which expose
>    platform bus compliant information (compat, sys/bus/platform...).
>  - PMDs which have deviations from this standard model can implement and
>    hook their bus scanning and probe match callbacks while registering
>    driver.

Yes we can have EAL helpers to scan sys/bus/platform or other common formats.
Then the PMD can use them to implement its specific bus.

I know that David, you and me are on the same page to agree on this generic
design. I hope you will be able to achieve this work soon.
The goal is to be able to plug a SoC driver in DPDK 17.02 with a clean design.
My advice to make reviews and contributions easier, is to split the work in
few steps:
	- clean PCI code (generalize non-PCI stuff)
	- add generic bus functions
	- plug PCI in generic bus abstraction
	- plug vdev in generic bus abstraction
	- plug the new NXP driver

Thanks