[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On 18 September 2016 at 15:22, Jan Viktorin wrote: > On Sun, 18 Sep 2016 13:58:50 +0800 > Jianbo Liu wrote: > >> On 9 September 2016 at 16:43, Shreyansh Jain >> wrote: >> > Introduction: >> > = >> > >> > This patch set is direct derivative of Jan's original series [1],[2]. >> > >> > - As this deviates substantially from original series, if need be I can >> >post it as a separate patch rather than v2. Please suggest. >> > - Also, there are comments on original v1 ([4]) which are _not_ >> >incorporated in this series as they refer to section no more in new >> >version. >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. >> >That series introduced device structures (rte_driver/rte_device) >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this >> >patchset, XXX=>SOC. > > [...] > >> > >> > 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 >> >> It could be many redundant code if Each PMD driver has the scan >> function if its own. >> I think Jan's implementation is common to many platform drivers. > > I personally can find a use case for having a custom scan function. > However, we should at least provide a default implementation. Probably, > both the scan and match functions should be used to _override_ a default > behaviour. So, only drivers that require to scan devices in a specific > way would provide a custom function for this. > And for each platform/product > I agree, that this can sometimes lead to code duplication. Moreover, it > opens door for a very non-standard, unsecure and wrong-by-design > approaches. I'd like more to provide one or more scan implementations > in EAL and do not put this responsibility on PMDs. > >> >> >detect the devices. This is because SoC may require specific or >> >additional info for device detection. Further, SoC may have embedded > > Can you provide an example for "additional info for device detection"? > >> >> Can you give us more precise definition about SoC driver? Does it >> include the driver in ARM server? > > I am sorry but I don't understand this question. > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > There is no "SoC driver" in the text so what definition are asking for? > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. I want to know what devices can use this SoC driver/device framework. Is it for the devices from ARM servers, or embedded systems of different vendors? And this framework is too generalized, if we don't try to understand "soc" in rte_soc_driver, we can use it for PCI devices. :) Thanks! Jianbo
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On 9 September 2016 at 16:43, Shreyansh Jain wrote: > Introduction: > = > > This patch set is direct derivative of Jan's original series [1],[2]. > > - As this deviates substantially from original series, if need be I can >post it as a separate patch rather than v2. Please suggest. > - Also, there are comments on original v1 ([4]) which are _not_ >incorporated in this series as they refer to section no more in new >version. > - This v3 version is based on the rte_driver/device patchset v9 [10]. >That series introduced device structures (rte_driver/rte_device) >generalizing devices into PCI, VDEV, XXX. For the purpose of this >patchset, XXX=>SOC. > > Aim: > > > As of now EAL is primarly focused on PCI initialization/probing. > > rte_eal_init() > |- rte_eal_pci_init(): Find PCI devices from sysfs > |- ... > |- rte_eal_memzone_init() > |- ... > `- rte_eal_pci_probe(): Driver<=>Device initialization > > 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 > > 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 It could be many redundant code if Each PMD driver has the scan function if its own. I think Jan's implementation is common to many platform drivers. >detect the devices. This is because SoC may require specific or >additional info for device detection. Further, SoC may have embedded Can you give us more precise definition about SoC driver? Does it include the driver in ARM server? >devices/MACs which require initialization which cannot be covered through >sysfs parsing. I think it can be done in devinit, not in scan function. devinit can be different for each driver. >= 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. >
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 09:41:55 + Hemant Agrawal wrote: > > -Original Message- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > [...] > > > And for each platform/product > > > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > > approaches. I'd like more to provide one or more scan > > > > implementations in EAL and do not put this responsibility on PMDs. > Hi Hemant. > [Hemant] A common/default scan function can be added, provided at least one > or more PMD driver support it. > w.r.t Jan's original scan function, it was not suitable for any of the NXP > SoC's whether ARM or PowerPC. > > Unable to validate the Jan's scan function on a real platform, we have > skipped it for next phase. > Addition of a default scan function can only be done in next phase, when we > find a suitable SoC PMD driver supporting it. Quite frankly, the situation is same for me. I still have no clue about your approach which seems to be pretty non-standard. I have no way how to test it. My approach can be tested on any Linux machine with platform devices and device-tree enabled. You would see that I detect those devices (I don't mean any certain network device, I mean all platform devices) and if you provide a driver with a proper compatible string it will be set for you. I presume that I don't have any upstreamable PMD for this at the moment.
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 16:56:54 +0800 Jianbo Liu wrote: > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > On Sun, 18 Sep 2016 13:58:50 +0800 > > Jianbo Liu wrote: > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > >> wrote: > >> > Introduction: > >> > = > >> > > >> > This patch set is direct derivative of Jan's original series [1],[2]. > >> > > >> > - As this deviates substantially from original series, if need be I can > >> >post it as a separate patch rather than v2. Please suggest. > >> > - Also, there are comments on original v1 ([4]) which are _not_ > >> >incorporated in this series as they refer to section no more in new > >> >version. > >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >> >That series introduced device structures (rte_driver/rte_device) > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >> >patchset, XXX=>SOC. > > > > [...] > > > >> > > >> > 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 > >> > > >> > >> It could be many redundant code if Each PMD driver has the scan > >> function if its own. > >> I think Jan's implementation is common to many platform drivers. > > > > I personally can find a use case for having a custom scan function. > > However, we should at least provide a default implementation. Probably, > > both the scan and match functions should be used to _override_ a default > > behaviour. So, only drivers that require to scan devices in a specific > > way would provide a custom function for this. > > > And for each platform/product > > > I agree, that this can sometimes lead to code duplication. Moreover, it > > opens door for a very non-standard, unsecure and wrong-by-design > > approaches. I'd like more to provide one or more scan implementations > > in EAL and do not put this responsibility on PMDs. > > > >> > >> >detect the devices. This is because SoC may require specific or > >> >additional info for device detection. Further, SoC may have embedded > > > > Can you provide an example for "additional info for device detection"? > > > >> > >> Can you give us more precise definition about SoC driver? Does it > >> include the driver in ARM server? > > > > I am sorry but I don't understand this question. > > > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > > > There is no "SoC driver" in the text so what definition are asking for? > > > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. > I want to know what devices can use this SoC driver/device framework. > Is it for the devices from ARM servers, or embedded systems of > different vendors? First, this is not an ARM-specific feature. Consider any MAC connected to the processor via some on-chip bus. In the world of ARM, it is usually a kind of AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example. Here they provide the Quick Path bus (but I don't know the details). So, you cannot access such device as PCI. It is usually not possible to distinguish the bus type easily (Linux calls this a platform device). So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on-Chip). Such devices can have a lower access latency because they are closer to the processor. So, if you have a server system driver by a SoC with integrated MACs (no PCI-E involved), there is no way how to access them from DPDK. An rte_soc_device represents such devices and provides a way how to access them from DPDK. That is the goal... You can have an embedded device (router, switch, monitoring device, NAT, firewall, anything in a "small box" with high throughput demands) that perfectly fits into this SoC framework because it would be usually based on some SoC (ARM, ARM64, ...). > And this framework is too generalized, if we don't try to understand > "soc" in rte_soc_driver, we can use it for PCI devices. :) No, you cannot use it for PCI devices, don't worry. There should be no PCI facilities like access to BARs :). But, I think I got your point. It seems to be generalized because there is no real standard in this area. Any vendor of SoC can provide her custom on-chip bus. The original idea was to build on top of the platform_device from Linux which hides this information from you (unless there is some bus-specific DMA which we must handle in the DPDK PMD). We could provide an rte_amba_device instead but there is no advantage in this. The amba bus is defined on the RTL level and not on the software level (no BARs, no device
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
> -Original Message- > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > On Sun, 18 Sep 2016 16:56:54 +0800 > Jianbo Liu wrote: > > > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > > On Sun, 18 Sep 2016 13:58:50 +0800 > > > Jianbo Liu wrote: > > > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > >> > Introduction: > > >> > = > > >> > > > >> > This patch set is direct derivative of Jan's original series [1],[2]. > > >> > > > >> > - As this deviates substantially from original series, if need be I > > >> > can > > >> >post it as a separate patch rather than v2. Please suggest. > > >> > - Also, there are comments on original v1 ([4]) which are _not_ > > >> >incorporated in this series as they refer to section no more in new > > >> >version. > > >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. > > >> >That series introduced device structures (rte_driver/rte_device) > > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this > > >> >patchset, XXX=>SOC. > > > > > > [...] > > > > > >> > > > >> > 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 > > >> > > >> It could be many redundant code if Each PMD driver has the scan > > >> function if its own. > > >> I think Jan's implementation is common to many platform drivers. > > > > > > I personally can find a use case for having a custom scan function. > > > However, we should at least provide a default implementation. > > > Probably, both the scan and match functions should be used to > > > _override_ a default behaviour. So, only drivers that require to > > > scan devices in a specific way would provide a custom function for this. > > > > > And for each platform/product > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > approaches. I'd like more to provide one or more scan > > > implementations in EAL and do not put this responsibility on PMDs. [Hemant] A common/default scan function can be added, provided at least one or more PMD driver support it. w.r.t Jan's original scan function, it was not suitable for any of the NXP SoC's whether ARM or PowerPC. Unable to validate the Jan's scan function on a real platform, we have skipped it for next phase. Addition of a default scan function can only be done in next phase, when we find a suitable SoC PMD driver supporting it. > > > > > >> > > >> >detect the devices. This is because SoC may require specific or > > >> >additional info for device detection. Further, SoC may have > > >> > embedded > > > > > > Can you provide an example for "additional info for device detection"? > > > > > >> > > >> Can you give us more precise definition about SoC driver? Does it > > >> include the driver in ARM server? > > > > > > I am sorry but I don't understand this question. > > > > > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > > > > > There is no "SoC driver" in the text so what definition are asking for? > > > > > This patchset introduces rte_soc_driver, which is inheriting from > > rte_driver. > > I want to know what devices can use this SoC driver/device framework. > > Is it for the devices from ARM servers, or embedded systems of > > different vendors? > > First, this is not an ARM-specific feature. Consider any MAC connected to the > processor via some on-chip bus. In the world of ARM, it is usually a kind of > AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example. > Here they provide the Quick Path bus (but I don't know the details). So, you > cannot access such device as PCI. It is usually not possible to distinguish > the bus > type easily (Linux calls this a platform device). > > So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on- > Chip). Such devices can have a lower access latency because they are closer to > the processor. > > So, if you have a server system driver by a SoC with integrated MACs (no PCI-E > involved), there is no way how to access them from DPDK. An rte_soc_device > represents such devices and provides a way how to access them from DPDK. > That is the goal... > > You can have an embedded device (router, switch, monitoring device, NAT, > firewall, anything in a "small box" with high throughput demands) that > perfectly > fits into this SoC framework because it would be usually based on some SoC > (ARM, ARM64, ...). > > > And this framework is too generalized, if we
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 13:58:50 +0800 Jianbo Liu wrote: > On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > Introduction: > > = > > > > This patch set is direct derivative of Jan's original series [1],[2]. > > > > - As this deviates substantially from original series, if need be I can > >post it as a separate patch rather than v2. Please suggest. > > - Also, there are comments on original v1 ([4]) which are _not_ > >incorporated in this series as they refer to section no more in new > >version. > > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >That series introduced device structures (rte_driver/rte_device) > >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >patchset, XXX=>SOC. [...] > > > > 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 > > It could be many redundant code if Each PMD driver has the scan > function if its own. > I think Jan's implementation is common to many platform drivers. I personally can find a use case for having a custom scan function. However, we should at least provide a default implementation. Probably, both the scan and match functions should be used to _override_ a default behaviour. So, only drivers that require to scan devices in a specific way would provide a custom function for this. I agree, that this can sometimes lead to code duplication. Moreover, it opens door for a very non-standard, unsecure and wrong-by-design approaches. I'd like more to provide one or more scan implementations in EAL and do not put this responsibility on PMDs. > > >detect the devices. This is because SoC may require specific or > >additional info for device detection. Further, SoC may have embedded Can you provide an example for "additional info for device detection"? > > Can you give us more precise definition about SoC driver? Does it > include the driver in ARM server? I am sorry but I don't understand this question. What you mean by a "driver in ARM server"? Do you mean a kernel driver? There is no "SoC driver" in the text so what definition are asking for? > > >devices/MACs which require initialization which cannot be covered through > >sysfs parsing. I think, the description itself is incorrect. If a device's initialization cannot be satisfied vie sysfs, it means that you have to write a specific probe function. This is not related to scan in any way. However, there may be a group of devices which are not managed by the standard platform_driver of the Linux Kernel (or other OS). In that case, the custom scan function would be helpful. I can imagine a device in a fully I/O coherent platform that only requires to access the /dev/mem only (for the register space). It is unsecure but it would work without any OS-driver. However, I consider it a corner case. It can be useful for testing sometimes but not very helpful for production. We should however support mainly the standard devices which are always represented by the OS. Otherwise, such system would introduce security issues. > > I think it can be done in devinit, not in scan function. devinit can > be different for each driver. +1 > > >= 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. > > Regards Jan -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
Hi David, > -Original Message- > From: Hunt, David [mailto:david.hunt at intel.com] > Sent: Thursday, September 15, 2016 6:26 PM > To: Shreyansh Jain ; dev at dpdk.org > Cc: viktorin at rehivetech.com; Hemant Agrawal > Subject: Re: [dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver > framework for EAL > > Shreyansh, Jan, Hemant, > > On 9/9/2016 9:43 AM, Shreyansh Jain wrote: > > Introduction: > > = > > > > This patch set is direct derivative of Jan's original series [1],[2]. > > > > - As this deviates substantially from original series, if need be I can > > post it as a separate patch rather than v2. Please suggest. > > - Also, there are comments on original v1 ([4]) which are _not_ > > incorporated in this series as they refer to section no more in new > > version. > > - This v3 version is based on the rte_driver/device patchset v9 [10]. > > That series introduced device structures (rte_driver/rte_device) > > generalizing devices into PCI, VDEV, XXX. For the purpose of this > > patchset, XXX=>SOC. > > > > > ---snip--- > > FYI, I've reviewed this patch set, and it looks to me like there's > some very good work here. Each patch in the set builds nicely on the one > before, and logically introduces the changes one by one. Great. Thank you so much for reviewing this series. It would really help us move it ahead and introduce other series which are based on it. > > I've no functional suggestions as the implementation looks clean, > but I've one or two tiny suggestions on headers and error messages. I'll > add a reply to the relevant patches in the set. I will have a look at those and fix them soon (v4). > > Also, there's one or two issues thrown up by checkpatch, but I suspect > they're false positives, as I'm using the 4.6 kernel version. Thanks for headup - I will see/fix those in v4, if any. > > Regards, > Dave > - Shreyansh
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
Shreyansh, Jan, Hemant, On 9/9/2016 9:43 AM, Shreyansh Jain wrote: > Introduction: > = > > This patch set is direct derivative of Jan's original series [1],[2]. > > - As this deviates substantially from original series, if need be I can > post it as a separate patch rather than v2. Please suggest. > - Also, there are comments on original v1 ([4]) which are _not_ > incorporated in this series as they refer to section no more in new > version. > - This v3 version is based on the rte_driver/device patchset v9 [10]. > That series introduced device structures (rte_driver/rte_device) > generalizing devices into PCI, VDEV, XXX. For the purpose of this > patchset, XXX=>SOC. > > ---snip--- FYI, I've reviewed this patch set, and it looks to me like there's some very good work here. Each patch in the set builds nicely on the one before, and logically introduces the changes one by one. I've no functional suggestions as the implementation looks clean, but I've one or two tiny suggestions on headers and error messages. I'll add a reply to the relevant patches in the set. Also, there's one or two issues thrown up by checkpatch, but I suspect they're false positives, as I'm using the 4.6 kernel version. Regards, Dave
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
Introduction: = This patch set is direct derivative of Jan's original series [1],[2]. - As this deviates substantially from original series, if need be I can post it as a separate patch rather than v2. Please suggest. - Also, there are comments on original v1 ([4]) which are _not_ incorporated in this series as they refer to section no more in new version. - This v3 version is based on the rte_driver/device patchset v9 [10]. That series introduced device structures (rte_driver/rte_device) generalizing devices into PCI, VDEV, XXX. For the purpose of this patchset, XXX=>SOC. Aim: As of now EAL is primarly focused on PCI initialization/probing. rte_eal_init() |- rte_eal_pci_init(): Find PCI devices from sysfs |- ... |- rte_eal_memzone_init() |- ... `- rte_eal_pci_probe(): Driver<=>Device initialization 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 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. = 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. Patchset Overview: == - Patches 0001~0003 introduce the base infrastructure and test case - Patch 0004 is for command line support for no-soc, on lines of no-pci - Patch 0005 enables EAL to handle SoC type devices - Patch 0006 adds support for scan and probe callbacks and updates the test framework with relevant test case. - Patch 0007~0009 enable device argument, driver specific flags and interrupt handling related basic infra. Subsequent patches build up on them. - Patch 0010~0013 makes changes to PCI as well as ethdev code to remove assumption that eth_driver is a PCI driver. - Patch 0014 adds necessary ethdev probe/remove functions for PMDs to use - Patch 0015 adds support for SoC driver/devices, along with probe/remove functions for Cryptodev devices. Future/Pending Changes: === - Device whitelisting/blacklist still relies on command line '-b' and '-c' which are internally implemented using OPT_PCI_BLACKLIST/OPT_PCI_WHITELIST. This needs to be changed to a generic form - OPT_DEV_*LIST - probably. - No cryptodriver currently uses SoC framework - probably a example driver can be created to demonstrate usage. [1] http://dpdk.org/ml/archives/dev/2016-January/030915.html [2] http://www.dpdk.org/ml/archives/dev/2016-May/038486.html [3] http://dpdk.org/ml/archives/dev/2016-August/045707.html [4] http://dpdk.org/ml/archives/dev/2016-May/038948.html [5]
