[dpdk-dev] [PATCH v7 00/21] Introduce SoC device/driver framework for EAL
Thomas Monjalon
thomas.monjalon at 6wind.com
Wed Nov 9 11:17:25 CET 2016
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
More information about the dev
mailing list