[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Thu, 16 Jun 2016 08:42:29 + Shreyansh Jain wrote: > Hi, > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Thursday, June 16, 2016 1:04 PM > > To: Shreyansh Jain > > Cc: David Marchand ; viktorin at > > rehivetech.com; > > dev at dpdk.org; Iremonger, Bernard > > Subject: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver > > > > 2016-06-16 06:32, Shreyansh Jain: > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, > > > Bernard > > > > Patches 3,8,16 and 17 no longer apply to the latest master branch. > > > > A rebase is needed. > > > > > > With the recent most head (04920e6): 01, 03, 08, 15, 16 and 17 are > > > failing. > > > > > > Just wanted to check if there is a rebase of this series anytime soon? > > > > I will take care of this series if time permit. > > Ok. > By the way, I have already rebased it on master. I can post the patches here > if you want. > (only trivial conflicts were there) Sounds good. +1 I'd rebase my patchset on top of it and repost. > > > It would help to have more reviews on other series touching EAL, like > > pmdinfo. > > Ok. I can try and review this, non-PCI/SoC and similar patchset in next few > days. The original David's patchset was quite OK. I didn't have any comments. The thing is (from my POV) that it was incomplete. Jan > > > > > > I was looking at Jan's non-PCI patchset [1] and they are based on this > > series. > > > > > > [1] > > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/30913/focus=38486 > > - > Shreyansh >
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Thu, 16 Jun 2016 11:19:59 +0200 Thomas Monjalon wrote: > 2016-06-16 10:23, Jan Viktorin: > > I think, we should consider to move it to somebody else. I would work on > > it, however, I don't see all the tasks that are to be done. That's why I > > was waiting to finalize those patchs by David or Thomas. For me, the > > important things were to generalize certain things to remove dependency on > > PCI. This is mostly done (otherwise the SoC patchset couldn't be done in > > the way I've posted it). > > > > Now, there is some pending work to remove pmd_type. Next, to find out some > > generalization of rte_pci_device/driver to create rte_device/driver (I've > > posted several suggestions in the of SoC patchset). For the pmd_type removal, I am not very sure about the original David's intentions. What should be the result? Should there be a special struct rte_virt_device or something like that? > > > > What more? > > We need a clean devargs API in EAL, not directly related to hotplug. > Then the hotplug can benefit of the devargs API as any other device config. Do we have some requirements for this? Would it be a complete redefinition of the API? I don't see the relations to hotplug. > > The EAL resources (also called devices) need an unique naming convention. > No idea about this. What do you mean by the unique naming convention? Jan
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
2016-06-16 10:23, Jan Viktorin: > I think, we should consider to move it to somebody else. I would work on it, > however, I don't see all the tasks that are to be done. That's why I was > waiting to finalize those patchs by David or Thomas. For me, the important > things were to generalize certain things to remove dependency on PCI. This is > mostly done (otherwise the SoC patchset couldn't be done in the way I've > posted it). > > Now, there is some pending work to remove pmd_type. Next, to find out some > generalization of rte_pci_device/driver to create rte_device/driver (I've > posted several suggestions in the of SoC patchset). > > What more? We need a clean devargs API in EAL, not directly related to hotplug. Then the hotplug can benefit of the devargs API as any other device config. The EAL resources (also called devices) need an unique naming convention.
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
I think, we should consider to move it to somebody else. I would work on it, however, I don't see all the tasks that are to be done. That's why I was waiting to finalize those patchs by David or Thomas. For me, the important things were to generalize certain things to remove dependency on PCI. This is mostly done (otherwise the SoC patchset couldn't be done in the way I've posted it). Now, there is some pending work to remove pmd_type. Next, to find out some generalization of rte_pci_device/driver to create rte_device/driver (I've posted several suggestions in the of SoC patchset). What more? Jan?Viktorin RehiveTech Sent?from?a?mobile?device ? P?vodn? zpr?va ? Od: Thomas Monjalon Odesl?no: ?tvrtek, 16. ?ervna 2016 9:34 Komu: Shreyansh Jain Kopie: David Marchand; viktorin at rehivetech.com; dev at dpdk.org; Iremonger, Bernard P?edm?t: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver 2016-06-16 06:32, Shreyansh Jain: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard > > Patches 3,8,16 and 17 no longer apply to the latest master branch. > > A rebase is needed. > > With the recent most head (04920e6): 01, 03, 08, 15, 16 and 17 are failing. > > Just wanted to check if there is a rebase of this series anytime soon? I will take care of this series if time permit. It would help to have more reviews on other series touching EAL, like pmdinfo. > I was looking at Jan's non-PCI patchset [1] and they are based on this series. > > [1] http://thread.gmane.org/gmane.comp.networking.dpdk.devel/30913/focus=38486
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Hi, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Thursday, June 16, 2016 1:04 PM > To: Shreyansh Jain > Cc: David Marchand ; viktorin at rehivetech.com; > dev at dpdk.org; Iremonger, Bernard > Subject: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver > > 2016-06-16 06:32, Shreyansh Jain: > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard > > > Patches 3,8,16 and 17 no longer apply to the latest master branch. > > > A rebase is needed. > > > > With the recent most head (04920e6): 01, 03, 08, 15, 16 and 17 are failing. > > > > Just wanted to check if there is a rebase of this series anytime soon? > > I will take care of this series if time permit. Ok. By the way, I have already rebased it on master. I can post the patches here if you want. (only trivial conflicts were there) > It would help to have more reviews on other series touching EAL, like > pmdinfo. Ok. I can try and review this, non-PCI/SoC and similar patchset in next few days. > > > I was looking at Jan's non-PCI patchset [1] and they are based on this > series. > > > > [1] > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/30913/focus=38486 - Shreyansh
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Hi David, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard > Sent: Friday, May 27, 2016 3:54 PM > To: David Marchand ; dev at dpdk.org > Cc: thomas.monjalon at 6wind.com; viktorin at rehivetech.com > Subject: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver > > Hi David, > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand > > Sent: Wednesday, April 20, 2016 12:44 PM > > To: dev at dpdk.org > > Cc: thomas.monjalon at 6wind.com; viktorin at rehivetech.com > > Subject: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver > > > > Following discussions with Jan [1] and some cleanup I started on pci code, > > here is a patchset that reworks pdev drivers registration and hotplug api. > > > > The structures changes mentioned in [1] are still to be done, but at least, > I > > think we are one step closer to it. > > > > Before this patchset, rte_driver .init semantics differed whether it > concerned > > a pdev or a vdev driver: > > - for vdev, it actually meant that a devargs is given to the driver so > > that it creates ethdev / crypto objects, so it was a probing action > > - for pdev, it only registered the driver triggering no ethdev / crypto > > objects > > > > From my pov, eal hotplug api introduced in this patchset still needs more > > work so that it does not need to know about devargs. So a new devargs api > is > > needed. > > > > Changes since v1: > > - rebased on HEAD, new drivers should be okay > > - patches have been split into smaller pieces > > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > > - device type has been removed from ethdev, as it was used only by hotplug > > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > > dropped for now, we can do this once vdev drivers have been converted > > > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > > > Regards, > > -- > > David Marchand > > > > David Marchand (17): > > pci: no need for dynamic tailq init > > crypto: no need for a crypto pmd type > > drivers: align pci driver definitions > > eal: remove duplicate function declaration > > eal: introduce init macros > > crypto: export init/uninit common wrappers for pci drivers > > ethdev: export init/uninit common wrappers for pci drivers > > drivers: convert all pdev drivers as pci drivers > > crypto: get rid of crypto driver register callback > > ethdev: get rid of eth driver register callback > > eal/linux: move back interrupt thread init before setting affinity > > pci: add a helper for device name > > pci: add a helper to update a device > > ethdev: do not scan all pci devices on attach > > eal: add hotplug operations for pci and vdev > > ethdev: convert to eal hotplug > > ethdev: get rid of device type > > > > app/test/virtual_pmd.c | 2 +- > > drivers/crypto/qat/rte_qat_cryptodev.c | 18 +- > > drivers/net/af_packet/rte_eth_af_packet.c | 2 +- > > drivers/net/bnx2x/bnx2x_ethdev.c| 35 +-- > > drivers/net/bonding/rte_eth_bond_api.c | 2 +- > > drivers/net/cxgbe/cxgbe_ethdev.c| 24 +- > > drivers/net/cxgbe/cxgbe_main.c | 2 +- > > drivers/net/e1000/em_ethdev.c | 16 +- > > drivers/net/e1000/igb_ethdev.c | 40 +-- > > drivers/net/ena/ena_ethdev.c| 20 +- > > drivers/net/enic/enic_ethdev.c | 23 +- > > drivers/net/fm10k/fm10k_ethdev.c| 23 +- > > drivers/net/i40e/i40e_ethdev.c | 26 +- > > drivers/net/i40e/i40e_ethdev_vf.c | 25 +- > > drivers/net/ixgbe/ixgbe_ethdev.c| 47 +--- > > drivers/net/mlx4/mlx4.c | 22 +- > > drivers/net/mlx5/mlx5.c | 21 +- > > drivers/net/mpipe/mpipe_tilegx.c| 2 +- > > drivers/net/nfp/nfp_net.c | 23 +- > > drivers/net/null/rte_eth_null.c | 2 +- > > drivers/net/pcap/rte_eth_pcap.c | 2 +- > > drivers/net/ring/rte_eth_ring.c | 2 +- > > drivers/net/szedata2/rte_eth_szedata2.c | 25 +- > > drivers/net/vhost/rte_eth_vhost.c | 2 +- > > drivers/net/virtio/virtio_ethdev.c |
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
2016-06-16 06:32, Shreyansh Jain: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Iremonger, Bernard > > Patches 3,8,16 and 17 no longer apply to the latest master branch. > > A rebase is needed. > > With the recent most head (04920e6): 01, 03, 08, 15, 16 and 17 are failing. > > Just wanted to check if there is a rebase of this series anytime soon? I will take care of this series if time permit. It would help to have more reviews on other series touching EAL, like pmdinfo. > I was looking at Jan's non-PCI patchset [1] and they are based on this series. > > [1] http://thread.gmane.org/gmane.comp.networking.dpdk.devel/30913/focus=38486
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Hi David, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand > Sent: Wednesday, April 20, 2016 12:44 PM > To: dev at dpdk.org > Cc: thomas.monjalon at 6wind.com; viktorin at rehivetech.com > Subject: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver > > Following discussions with Jan [1] and some cleanup I started on pci code, > here is a patchset that reworks pdev drivers registration and hotplug api. > > The structures changes mentioned in [1] are still to be done, but at least, I > think we are one step closer to it. > > Before this patchset, rte_driver .init semantics differed whether it concerned > a pdev or a vdev driver: > - for vdev, it actually meant that a devargs is given to the driver so > that it creates ethdev / crypto objects, so it was a probing action > - for pdev, it only registered the driver triggering no ethdev / crypto > objects > > From my pov, eal hotplug api introduced in this patchset still needs more > work so that it does not need to know about devargs. So a new devargs api is > needed. > > Changes since v1: > - rebased on HEAD, new drivers should be okay > - patches have been split into smaller pieces > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > - device type has been removed from ethdev, as it was used only by hotplug > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > dropped for now, we can do this once vdev drivers have been converted > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > Regards, > -- > David Marchand > > David Marchand (17): > pci: no need for dynamic tailq init > crypto: no need for a crypto pmd type > drivers: align pci driver definitions > eal: remove duplicate function declaration > eal: introduce init macros > crypto: export init/uninit common wrappers for pci drivers > ethdev: export init/uninit common wrappers for pci drivers > drivers: convert all pdev drivers as pci drivers > crypto: get rid of crypto driver register callback > ethdev: get rid of eth driver register callback > eal/linux: move back interrupt thread init before setting affinity > pci: add a helper for device name > pci: add a helper to update a device > ethdev: do not scan all pci devices on attach > eal: add hotplug operations for pci and vdev > ethdev: convert to eal hotplug > ethdev: get rid of device type > > app/test/virtual_pmd.c | 2 +- > drivers/crypto/qat/rte_qat_cryptodev.c | 18 +- > drivers/net/af_packet/rte_eth_af_packet.c | 2 +- > drivers/net/bnx2x/bnx2x_ethdev.c| 35 +-- > drivers/net/bonding/rte_eth_bond_api.c | 2 +- > drivers/net/cxgbe/cxgbe_ethdev.c| 24 +- > drivers/net/cxgbe/cxgbe_main.c | 2 +- > drivers/net/e1000/em_ethdev.c | 16 +- > drivers/net/e1000/igb_ethdev.c | 40 +-- > drivers/net/ena/ena_ethdev.c| 20 +- > drivers/net/enic/enic_ethdev.c | 23 +- > drivers/net/fm10k/fm10k_ethdev.c| 23 +- > drivers/net/i40e/i40e_ethdev.c | 26 +- > drivers/net/i40e/i40e_ethdev_vf.c | 25 +- > drivers/net/ixgbe/ixgbe_ethdev.c| 47 +--- > drivers/net/mlx4/mlx4.c | 22 +- > drivers/net/mlx5/mlx5.c | 21 +- > drivers/net/mpipe/mpipe_tilegx.c| 2 +- > drivers/net/nfp/nfp_net.c | 23 +- > drivers/net/null/rte_eth_null.c | 2 +- > drivers/net/pcap/rte_eth_pcap.c | 2 +- > drivers/net/ring/rte_eth_ring.c | 2 +- > drivers/net/szedata2/rte_eth_szedata2.c | 25 +- > drivers/net/vhost/rte_eth_vhost.c | 2 +- > drivers/net/virtio/virtio_ethdev.c | 26 +- > drivers/net/vmxnet3/vmxnet3_ethdev.c| 23 +- > drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +- > examples/ip_pipeline/init.c | 22 -- > lib/librte_cryptodev/rte_cryptodev.c| 67 + > lib/librte_cryptodev/rte_cryptodev.h| 2 - > lib/librte_cryptodev/rte_cryptodev_pmd.h| 45 +--- > lib/librte_cryptodev/rte_cryptodev_version.map | 9 +- > lib/librte_eal/bsdapp/eal/eal_pci.c | 52 +++- > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 8 + > lib/librte_eal/common/eal_common_dev.c | 39 +++ > lib/librte_eal/common/eal_common_pci.c | 17 +- > lib/librte_eal/common/eal_private.h | 20 +- > lib/librt
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Hello, On Fri, 6 May 2016 10:26:45 +0100 Declan Doherty wrote: > On 20/04/16 13:41, Jan Viktorin wrote: > > On Wed, 20 Apr 2016 13:05:24 +0100 > > Bruce Richardson wrote: > > > >> On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: > >>> Following discussions with Jan [1] and some cleanup I started on pci code, > >>> here is a patchset that reworks pdev drivers registration and hotplug api. > >>> [...] > > The changes look good to me, nice to remove some of the duplication > ethdev/cryptodev. Yes, I like them too. > > Regarding enabling hot-plugging for crypto devices it looks like it > should be possible now to implement a mostly generic device > attach/detach functions, just with a simple wrapper to identify a > specific crypto or ethdev device structure. Do you have plans to do > this? If not, I can have a look as I would like to enable hot-plugging Yes. But, first I focused on the new SoC infra to find out what can be shared by the generic layer. I've got almost ready patch series, I will post it soon to the mailing list. It does not introduce the generic rte_driver/device yet, however, it shows that with [PATCH v2 00/17] prepare for rte_device / rte_driver it is now possible to do it quite easily. However, what I am not very sure about is whether we separate management of the PCI devices and SoC devices and any other such devices. Or whether we should have a single list for all. Second, the rte_driver must be removed from DPDK as it conflicts with the new rte_driver structure to be introduced. This should include removing of pmd_type, I think. I've expected that David M. will continue with v3 to move on (otherwise we'll get some merge conflicts I'd like to avoid). Another thing, there are structs like rte_pci_addr (etc.) which must (but I am not so sure) be probably generalized as well. And, devargs... Regards Jan > for crypto devices, without duplicating things that still reside in the > ethdev library at the moment. > -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On 20/04/16 13:41, Jan Viktorin wrote: > On Wed, 20 Apr 2016 13:05:24 +0100 > Bruce Richardson wrote: > >> On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: >>> Following discussions with Jan [1] and some cleanup I started on pci code, >>> here is a patchset that reworks pdev drivers registration and hotplug api. >>> >>> The structures changes mentioned in [1] are still to be done, but at least, >>> I think we are one step closer to it. >>> >>> Before this patchset, rte_driver .init semantics differed whether it >>> concerned a pdev or a vdev driver: >>> - for vdev, it actually meant that a devargs is given to the driver so >>> that it creates ethdev / crypto objects, so it was a probing action >>> - for pdev, it only registered the driver triggering no ethdev / crypto >>> objects >>> >>> From my pov, eal hotplug api introduced in this patchset still needs more >>> work so that it does not need to know about devargs. So a new devargs api >>> is needed. >>> >>> Changes since v1: >>> - rebased on HEAD, new drivers should be okay >>> - patches have been split into smaller pieces >>> - RTE_INIT macro has been added, but in the end, I am not sure it is useful >>> - device type has been removed from ethdev, as it was used only by hotplug >>> - getting rid of pmd type in eal patch (patch 5 of initial series) has been >>> dropped for now, we can do this once vdev drivers have been converted >>> >>> [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html >>> >>> Regards, >>> -- >>> David Marchand >>> >> Nice, David. Looks to be some good improvements in there! >> >> /Bruce > > Looks good for me but I've failed to apply the series on top of > > commit 7d619406f31ddf115714b32778c33f6dc0ead470 > Author: Thomas Monjalon > Date: Thu Apr 14 20:49:49 2016 +0200 > > pci: remove deprecated specific config > > Jan > The changes look good to me, nice to remove some of the duplication ethdev/cryptodev. Regarding enabling hot-plugging for crypto devices it looks like it should be possible now to implement a mostly generic device attach/detach functions, just with a simple wrapper to identify a specific crypto or ethdev device structure. Do you have plans to do this? If not, I can have a look as I would like to enable hot-plugging for crypto devices, without duplicating things that still reside in the ethdev library at the moment.
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
[...] > > > > > > Changes since v1: > > > - rebased on HEAD, new drivers should be okay > > > - patches have been split into smaller pieces > > > - RTE_INIT macro has been added, but in the end, I am not sure it is > > > useful > > > - device type has been removed from ethdev, as it was used only by hotplug > > > - getting rid of pmd type in eal patch (patch 5 of initial series) has > > > been > > > dropped for now, we can do this once vdev drivers have been converted > > > > > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > > > > > Regards, > > > -- > > > David Marchand > > > > > Nice, David. Looks to be some good improvements in there! > > > > /Bruce > > Looks good for me but I've failed to apply the series on top of > > commit 7d619406f31ddf115714b32778c33f6dc0ead470 > Author: Thomas Monjalon > Date: Thu Apr 14 20:49:49 2016 +0200 > > pci: remove deprecated specific config OK, it works, my fault. What is the way of removing the pmd_type? Would you like to introduce something like rte_virt_device/driver pair for this purpose? Or should they use the rte_device/rte_driver directly? Other points: * The devinit/devuninit should be generalized and moved to rte_driver, right? * Fields name, drv_flags should be moved to rte_driver. * Fields devargs, intr_handle, numa_node should be moved to rte_device. * Do we want getter/setters for those? Otherwise, it always looks like pci_dev->dev.numa_node. * What about pci_driver_list and pci_device_list? Should we have separated lists for every kind of device + driver? or should there be a single list (and so we have to put some discriminator into the rte_device/driver)? This influences placing of the TAILQ_ENTRY(...) next. * if we move the next into the rte_driver/device and a discriminator of their type there, all TAILQ_FOREACH loops will look ugly as we have to check the discriminator... Regards Jan > > Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Wed, 20 Apr 2016 13:05:24 +0100 Bruce Richardson wrote: > On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: > > Following discussions with Jan [1] and some cleanup I started on pci code, > > here is a patchset that reworks pdev drivers registration and hotplug api. > > > > The structures changes mentioned in [1] are still to be done, but at least, > > I think we are one step closer to it. > > > > Before this patchset, rte_driver .init semantics differed whether it > > concerned a pdev or a vdev driver: > > - for vdev, it actually meant that a devargs is given to the driver so > > that it creates ethdev / crypto objects, so it was a probing action > > - for pdev, it only registered the driver triggering no ethdev / crypto > > objects > > > > From my pov, eal hotplug api introduced in this patchset still needs more > > work so that it does not need to know about devargs. So a new devargs api > > is needed. > > > > Changes since v1: > > - rebased on HEAD, new drivers should be okay > > - patches have been split into smaller pieces > > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > > - device type has been removed from ethdev, as it was used only by hotplug > > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > > dropped for now, we can do this once vdev drivers have been converted > > > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > > > Regards, > > -- > > David Marchand > > > Nice, David. Looks to be some good improvements in there! > > /Bruce Looks good for me but I've failed to apply the series on top of commit 7d619406f31ddf115714b32778c33f6dc0ead470 Author: Thomas Monjalon Date: Thu Apr 14 20:49:49 2016 +0200 pci: remove deprecated specific config Jan
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
Following discussions with Jan [1] and some cleanup I started on pci code, here is a patchset that reworks pdev drivers registration and hotplug api. The structures changes mentioned in [1] are still to be done, but at least, I think we are one step closer to it. Before this patchset, rte_driver .init semantics differed whether it concerned a pdev or a vdev driver: - for vdev, it actually meant that a devargs is given to the driver so that it creates ethdev / crypto objects, so it was a probing action - for pdev, it only registered the driver triggering no ethdev / crypto objects >From my pov, eal hotplug api introduced in this patchset still needs more work so that it does not need to know about devargs. So a new devargs api is needed. Changes since v1: - rebased on HEAD, new drivers should be okay - patches have been split into smaller pieces - RTE_INIT macro has been added, but in the end, I am not sure it is useful - device type has been removed from ethdev, as it was used only by hotplug - getting rid of pmd type in eal patch (patch 5 of initial series) has been dropped for now, we can do this once vdev drivers have been converted [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html Regards, -- David Marchand David Marchand (17): pci: no need for dynamic tailq init crypto: no need for a crypto pmd type drivers: align pci driver definitions eal: remove duplicate function declaration eal: introduce init macros crypto: export init/uninit common wrappers for pci drivers ethdev: export init/uninit common wrappers for pci drivers drivers: convert all pdev drivers as pci drivers crypto: get rid of crypto driver register callback ethdev: get rid of eth driver register callback eal/linux: move back interrupt thread init before setting affinity pci: add a helper for device name pci: add a helper to update a device ethdev: do not scan all pci devices on attach eal: add hotplug operations for pci and vdev ethdev: convert to eal hotplug ethdev: get rid of device type app/test/virtual_pmd.c | 2 +- drivers/crypto/qat/rte_qat_cryptodev.c | 18 +- drivers/net/af_packet/rte_eth_af_packet.c | 2 +- drivers/net/bnx2x/bnx2x_ethdev.c| 35 +-- drivers/net/bonding/rte_eth_bond_api.c | 2 +- drivers/net/cxgbe/cxgbe_ethdev.c| 24 +- drivers/net/cxgbe/cxgbe_main.c | 2 +- drivers/net/e1000/em_ethdev.c | 16 +- drivers/net/e1000/igb_ethdev.c | 40 +-- drivers/net/ena/ena_ethdev.c| 20 +- drivers/net/enic/enic_ethdev.c | 23 +- drivers/net/fm10k/fm10k_ethdev.c| 23 +- drivers/net/i40e/i40e_ethdev.c | 26 +- drivers/net/i40e/i40e_ethdev_vf.c | 25 +- drivers/net/ixgbe/ixgbe_ethdev.c| 47 +--- drivers/net/mlx4/mlx4.c | 22 +- drivers/net/mlx5/mlx5.c | 21 +- drivers/net/mpipe/mpipe_tilegx.c| 2 +- drivers/net/nfp/nfp_net.c | 23 +- drivers/net/null/rte_eth_null.c | 2 +- drivers/net/pcap/rte_eth_pcap.c | 2 +- drivers/net/ring/rte_eth_ring.c | 2 +- drivers/net/szedata2/rte_eth_szedata2.c | 25 +- drivers/net/vhost/rte_eth_vhost.c | 2 +- drivers/net/virtio/virtio_ethdev.c | 26 +- drivers/net/vmxnet3/vmxnet3_ethdev.c| 23 +- drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +- examples/ip_pipeline/init.c | 22 -- lib/librte_cryptodev/rte_cryptodev.c| 67 + lib/librte_cryptodev/rte_cryptodev.h| 2 - lib/librte_cryptodev/rte_cryptodev_pmd.h| 45 +--- lib/librte_cryptodev/rte_cryptodev_version.map | 9 +- lib/librte_eal/bsdapp/eal/eal_pci.c | 52 +++- lib/librte_eal/bsdapp/eal/rte_eal_version.map | 8 + lib/librte_eal/common/eal_common_dev.c | 39 +++ lib/librte_eal/common/eal_common_pci.c | 17 +- lib/librte_eal/common/eal_private.h | 20 +- lib/librte_eal/common/include/rte_dev.h | 29 ++- lib/librte_eal/common/include/rte_eal.h | 3 + lib/librte_eal/common/include/rte_pci.h | 32 +++ lib/librte_eal/common/include/rte_tailq.h | 4 +- lib/librte_eal/linuxapp/eal/eal.c | 7 +- lib/librte_eal/linuxapp/eal/eal_pci.c | 16 +- lib/librte_eal/linuxapp/eal/rte_eal_version.map | 8 + lib/librte_ether/rte_ethdev.c | 316 lib/librte_ether/rte_ethdev.h | 40 ++- lib/librte_ether/rte_ether_version.map | 9 +- 47 files changed, 392 insertions(+), 810 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver
On Wed, Apr 20, 2016 at 01:44:00PM +0200, David Marchand wrote: > Following discussions with Jan [1] and some cleanup I started on pci code, > here is a patchset that reworks pdev drivers registration and hotplug api. > > The structures changes mentioned in [1] are still to be done, but at least, > I think we are one step closer to it. > > Before this patchset, rte_driver .init semantics differed whether it > concerned a pdev or a vdev driver: > - for vdev, it actually meant that a devargs is given to the driver so > that it creates ethdev / crypto objects, so it was a probing action > - for pdev, it only registered the driver triggering no ethdev / crypto > objects > > From my pov, eal hotplug api introduced in this patchset still needs more > work so that it does not need to know about devargs. So a new devargs api > is needed. > > Changes since v1: > - rebased on HEAD, new drivers should be okay > - patches have been split into smaller pieces > - RTE_INIT macro has been added, but in the end, I am not sure it is useful > - device type has been removed from ethdev, as it was used only by hotplug > - getting rid of pmd type in eal patch (patch 5 of initial series) has been > dropped for now, we can do this once vdev drivers have been converted > > [1] http://dpdk.org/ml/archives/dev/2016-January/031390.html > > Regards, > -- > David Marchand > Nice, David. Looks to be some good improvements in there! /Bruce
