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