| Message ID | 1443445418-18498-3-git-send-email-bernard.iremonger@intel.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, Sep 28, 2015 at 02:03:20PM +0100, Bernard Iremonger wrote: > add dev_flags to rte_eth_dev_data, add macros for dev_flags. > add kdrv to rte_eth_dev_data. > add numa_node to rte_eth_dev_data. > add drv_name to rte_eth_dev_data. > use dev_type to distinguish between vdev's and pdev's. > remove pci_dev branches. > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > --- > lib/librte_ether/rte_ethdev.c | 53 ++++++++++++++++++++++++------------------- > lib/librte_ether/rte_ethdev.h | 15 ++++++++++++ > 2 files changed, 45 insertions(+), 23 deletions(-) > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c > index b309309..e4cb285 100644 > --- a/lib/librte_ether/rte_ethdev.c > +++ b/lib/librte_ether/rte_ethdev.c > @@ -424,7 +424,7 @@ rte_eth_dev_socket_id(uint8_t port_id) > { > if (!rte_eth_dev_is_valid_port(port_id)) > return -1; > - return rte_eth_devices[port_id].pci_dev->numa_node; > + return rte_eth_devices[port_id].data->numa_node; > } > > uint8_t > @@ -503,27 +503,25 @@ rte_eth_dev_get_name_by_port(uint8_t port_id, char *name) > static int > rte_eth_dev_is_detachable(uint8_t port_id) > { > - uint32_t drv_flags; > + uint32_t dev_flags; > > if (!rte_eth_dev_is_valid_port(port_id)) { > PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id); > return -EINVAL; > } > > - if (rte_eth_devices[port_id].dev_type == RTE_ETH_DEV_PCI) { > - switch (rte_eth_devices[port_id].pci_dev->kdrv) { > - case RTE_KDRV_IGB_UIO: > - case RTE_KDRV_UIO_GENERIC: > - case RTE_KDRV_NIC_UIO: > - break; > - case RTE_KDRV_VFIO: > - default: > - return -ENOTSUP; > - } > + switch (rte_eth_devices[port_id].data->kdrv) { > + case RTE_KDRV_IGB_UIO: > + case RTE_KDRV_UIO_GENERIC: > + case RTE_KDRV_NIC_UIO: > + case RTE_KDRV_NONE: > + break; > + case RTE_KDRV_VFIO: > + default: > + return -ENOTSUP; > } > - > - drv_flags = rte_eth_devices[port_id].driver->pci_drv.drv_flags; > - return !(drv_flags & RTE_PCI_DRV_DETACHABLE); > + dev_flags = rte_eth_devices[port_id].data->dev_flags; > + return !(dev_flags & RTE_ETH_DEV_DETACHABLE); > } > > /* attach the new physical device, then store port_id of the device */ > @@ -1143,14 +1141,11 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, > * If link state interrupt is enabled, check that the > * device supports it. > */ > - if (dev_conf->intr_conf.lsc == 1) { > - const struct rte_pci_driver *pci_drv = &dev->driver->pci_drv; > - > - if (!(pci_drv->drv_flags & RTE_PCI_DRV_INTR_LSC)) { > + if ((dev_conf->intr_conf.lsc == 1) && > + (!(dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC))) { > PMD_DEBUG_TRACE("driver %s does not support lsc\n", > - pci_drv->name); > + dev->data->drv_name); > return -EINVAL; > - } > } > > /* > @@ -1795,8 +1790,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info) > FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get); > (*dev->dev_ops->dev_infos_get)(dev, dev_info); > dev_info->pci_dev = dev->pci_dev; > - if (dev->driver) > - dev_info->driver_name = dev->driver->pci_drv.name; > + dev_info->driver_name = dev->data->drv_name; > } > > void > @@ -3570,3 +3564,16 @@ rte_eth_dev_set_eeprom(uint8_t port_id, struct rte_dev_eeprom_info *info) > FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_eeprom, -ENOTSUP); > return (*dev->dev_ops->set_eeprom)(dev, info); > } > + > +void > +rte_eth_copy_dev_info(struct rte_eth_dev *eth_dev, struct rte_pci_device *pci_dev) > +{ > + if ((eth_dev == NULL) || (pci_dev == NULL)) > + PMD_DEBUG_TRACE("NULL pointer eth_dev=%p pci_dev=%p\n", > + eth_dev, pci_dev); > + > + eth_dev->data->dev_flags = pci_dev->driver->drv_flags; > + eth_dev->data->kdrv = pci_dev->kdrv; > + eth_dev->data->numa_node = pci_dev->numa_node; > + eth_dev->data->drv_name = pci_dev->driver->name; > +} > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > index fa06554..9cd262b 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > + uint32_t dev_flags; /**< Flags controlling handling of device. */ > + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ Why add this here? The ennumerated driver types are all variants on PCI bus types. Not sure why the ethernet interface needs to know this info > + int numa_node; Ditto, this seems like information that is only relevant if the device is on a physical bus (i.e. virual devices are likely to not have a numa node) > + const char *drv_name; > }; > > +/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */ > +#define RTE_ETH_DEV_DRV_NEED_MAPPING RTE_PCI_DRV_NEED_MAPPING > +/** Device needs to be unbound even if no module is provided */ > +#define RTE_ETH_DEV_DRV_FORCE_UNBIND RTE_PCI_DRV_FORCE_UNBIND > +/** Device supports link state interrupt */ > +#define RTE_ETH_DEV_INTR_LSC RTE_PCI_DRV_INTR_LSC > +/** Device supports detaching capability */ > +#define RTE_ETH_DEV_DETACHABLE RTE_PCI_DRV_DETACHABLE > +/** Device is a bonded device */ > +#define RTE_ETH_DEV_BONDED 0x0020 > + > /** > * @internal > * The pool of *rte_eth_dev* structures. The size of the pool > -- > 1.9.1 > >
On Tue, Sep 29, 2015 at 03:08:12PM -0400, Neil Horman wrote: > On Mon, Sep 28, 2015 at 02:03:20PM +0100, Bernard Iremonger wrote: > > add dev_flags to rte_eth_dev_data, add macros for dev_flags. > > add kdrv to rte_eth_dev_data. > > add numa_node to rte_eth_dev_data. > > add drv_name to rte_eth_dev_data. > > use dev_type to distinguish between vdev's and pdev's. > > remove pci_dev branches. > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > --- > > lib/librte_ether/rte_ethdev.c | 53 ++++++++++++++++++++++++------------------- > > lib/librte_ether/rte_ethdev.h | 15 ++++++++++++ > > 2 files changed, 45 insertions(+), 23 deletions(-) > > <snip> > > +++ b/lib/librte_ether/rte_ethdev.h > > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > > all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > > dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > > + uint32_t dev_flags; /**< Flags controlling handling of device. */ > > + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ > Why add this here? The ennumerated driver types are all variants on PCI bus > types. Not sure why the ethernet interface needs to know this info > > > + int numa_node; > Ditto, this seems like information that is only relevant if the device is on a > physical bus (i.e. virual devices are likely to not have a numa node) > Actually, I disagree. For some virtual devices they will have a numa node. For ring or other virtual PMDs the numa node will be the node on which the ring / mempool etc. memory is allocated on, and can be of relevance. /Bruce
On Wed, Sep 30, 2015 at 10:56:04AM +0100, Bruce Richardson wrote: > On Tue, Sep 29, 2015 at 03:08:12PM -0400, Neil Horman wrote: > > On Mon, Sep 28, 2015 at 02:03:20PM +0100, Bernard Iremonger wrote: > > > add dev_flags to rte_eth_dev_data, add macros for dev_flags. > > > add kdrv to rte_eth_dev_data. > > > add numa_node to rte_eth_dev_data. > > > add drv_name to rte_eth_dev_data. > > > use dev_type to distinguish between vdev's and pdev's. > > > remove pci_dev branches. > > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > > --- > > > lib/librte_ether/rte_ethdev.c | 53 ++++++++++++++++++++++++------------------- > > > lib/librte_ether/rte_ethdev.h | 15 ++++++++++++ > > > 2 files changed, 45 insertions(+), 23 deletions(-) > > > > <snip> > > > +++ b/lib/librte_ether/rte_ethdev.h > > > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > > > all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > > > dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > > > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > > > + uint32_t dev_flags; /**< Flags controlling handling of device. */ > > > + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ > > Why add this here? The ennumerated driver types are all variants on PCI bus > > types. Not sure why the ethernet interface needs to know this info > > > > > + int numa_node; > > Ditto, this seems like information that is only relevant if the device is on a > > physical bus (i.e. virual devices are likely to not have a numa node) > > > Actually, I disagree. For some virtual devices they will have a numa node. For > ring or other virtual PMDs the numa node will be the node on which the ring / > mempool etc. memory is allocated on, and can be of relevance. > > /Bruce > I think its fairly clear that some devices (including virtual ones) have some relevant relation to a numa_node (There are even some that have no numa_node, for which a -1 value makes some sense). That said, there are just as many that don't have a relevant numa_node. 1) There are some drivers for which numa_node make no sense (regardless of value): * af_packet - The numa node is at best determined at run time by the interface the socket is bound to * pcap - same as af_packet * bonding - multiple interfaces mean multiple numa_nodes, any value set here is just as likely to be wrong as right * mpipe - no real large memory area to associate with a numa node * virtio - uses iopl for communication, and cannot know its numa_node * vmxnet3 - same concept as virtio * xenvirt - same as vmxnet3 I think its better that you store numa locality information in a pmd's private bus data, and export it to applications via a device method. that provides the flexibility to tell the application that there is no numa locality for a device (by not implementing the method), without having to expose an unset data field to the application. Neil
> +} > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > index fa06554..9cd262b 100644 > --- a/lib/librte_ether/rte_ethdev.h > +++ b/lib/librte_ether/rte_ethdev.h > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > + uint32_t dev_flags; /**< Flags controlling handling of device. */ > + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ > + int numa_node; > + const char *drv_name; > }; > Unrelated to my other questions on this code: Is rte_eth_dev_data ever allocation by any applications? If so, this will have to go through the ABI process. I don't think it is, but I wanted to ask to be sure Neil > +/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */ > +#define RTE_ETH_DEV_DRV_NEED_MAPPING RTE_PCI_DRV_NEED_MAPPING > +/** Device needs to be unbound even if no module is provided */ > +#define RTE_ETH_DEV_DRV_FORCE_UNBIND RTE_PCI_DRV_FORCE_UNBIND > +/** Device supports link state interrupt */ > +#define RTE_ETH_DEV_INTR_LSC RTE_PCI_DRV_INTR_LSC > +/** Device supports detaching capability */ > +#define RTE_ETH_DEV_DETACHABLE RTE_PCI_DRV_DETACHABLE > +/** Device is a bonded device */ > +#define RTE_ETH_DEV_BONDED 0x0020 > + > /** > * @internal > * The pool of *rte_eth_dev* structures. The size of the pool > -- > 1.9.1 > >
On Wed, Sep 30, 2015 at 09:14:48AM -0400, Neil Horman wrote: > On Wed, Sep 30, 2015 at 10:56:04AM +0100, Bruce Richardson wrote: > > On Tue, Sep 29, 2015 at 03:08:12PM -0400, Neil Horman wrote: > > > On Mon, Sep 28, 2015 at 02:03:20PM +0100, Bernard Iremonger wrote: > > > > add dev_flags to rte_eth_dev_data, add macros for dev_flags. > > > > add kdrv to rte_eth_dev_data. > > > > add numa_node to rte_eth_dev_data. > > > > add drv_name to rte_eth_dev_data. > > > > use dev_type to distinguish between vdev's and pdev's. > > > > remove pci_dev branches. > > > > > > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> > > > > --- > > > > lib/librte_ether/rte_ethdev.c | 53 ++++++++++++++++++++++++------------------- > > > > lib/librte_ether/rte_ethdev.h | 15 ++++++++++++ > > > > 2 files changed, 45 insertions(+), 23 deletions(-) > > > > > > <snip> > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > > > > all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > > > > dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > > > > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > > > > + uint32_t dev_flags; /**< Flags controlling handling of device. */ > > > > + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ > > > Why add this here? The ennumerated driver types are all variants on PCI bus > > > types. Not sure why the ethernet interface needs to know this info > > > > > > > + int numa_node; > > > Ditto, this seems like information that is only relevant if the device is on a > > > physical bus (i.e. virual devices are likely to not have a numa node) > > > > > Actually, I disagree. For some virtual devices they will have a numa node. For > > ring or other virtual PMDs the numa node will be the node on which the ring / > > mempool etc. memory is allocated on, and can be of relevance. > > > > /Bruce > > > > I think its fairly clear that some devices (including virtual ones) have some > relevant relation to a numa_node (There are even some that have no numa_node, > for which a -1 value makes some sense). That said, there are just as many that > don't have a relevant numa_node. > > 1) There are some drivers for which numa_node make no sense (regardless of > value): > * af_packet - The numa node is at best determined at run time by the interface > the socket is bound to > > * pcap - same as af_packet > > * bonding - multiple interfaces mean multiple numa_nodes, any value set here is > just as likely to be wrong as right > > * mpipe - no real large memory area to associate with a numa node > > * virtio - uses iopl for communication, and cannot know its numa_node > > * vmxnet3 - same concept as virtio > > * xenvirt - same as vmxnet3 > > I think its better that you store numa locality information in a pmd's private > bus data, and export it to applications via a device method. that provides the > flexibility to tell the application that there is no numa locality for a device > (by not implementing the method), without having to expose an unset data field > to the application. > > Neil > Sure, that could work. However, is it really worthwhile asking drivers to implement a new ethdev API function, rather than just having them set the numa node field correctly in the init function? /Bruce
On Wed, Sep 30, 2015 at 09:18:53AM -0400, Neil Horman wrote: > > +} > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h > > index fa06554..9cd262b 100644 > > --- a/lib/librte_ether/rte_ethdev.h > > +++ b/lib/librte_ether/rte_ethdev.h > > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > > all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ > > dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ > > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > > + uint32_t dev_flags; /**< Flags controlling handling of device. */ > > + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ > > + int numa_node; > > + const char *drv_name; > > }; > > > Unrelated to my other questions on this code: Is rte_eth_dev_data ever > allocation by any applications? If so, this will have to go through the ABI > process. I don't think it is, but I wanted to ask to be sure > > Neil > No - applications do not allocate this structure directly, it's internal only, so we should be safe here from an ABI perspective. /Bruce
Hi Neil <snip> > > > > > +++ b/lib/librte_ether/rte_ethdev.h > > > > > @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { > > > > > all_multicast : 1, /**< RX all multicast mode ON(1) / > OFF(0). */ > > > > > dev_started : 1, /**< Device state: STARTED(1) / > STOPPED(0). */ > > > > > lro : 1; /**< RX LRO is ON(1) / OFF(0) */ > > > > > + uint32_t dev_flags; /**< Flags controlling handling of device. > */ > > > > > + enum rte_kernel_driver kdrv; /**< Kernel driver > passthrough */ > > > > Why add this here? The ennumerated driver types are all variants > > > > on PCI bus types. Not sure why the ethernet interface needs to > > > > know this info > > > > > > > > > + int numa_node; > > > > Ditto, this seems like information that is only relevant if the > > > > device is on a physical bus (i.e. virual devices are likely to not > > > > have a numa node) > > > > > > > Actually, I disagree. For some virtual devices they will have a numa > > > node. For ring or other virtual PMDs the numa node will be the node > > > on which the ring / mempool etc. memory is allocated on, and can be of > relevance. > > > > > > /Bruce > > > > > > > I think its fairly clear that some devices (including virtual ones) > > have some relevant relation to a numa_node (There are even some that > > have no numa_node, for which a -1 value makes some sense). That said, > > there are just as many that don't have a relevant numa_node. > > > > 1) There are some drivers for which numa_node make no sense > > (regardless of > > value): > > * af_packet - The numa node is at best determined at run time by the > > interface the socket is bound to > > > > * pcap - same as af_packet > > > > * bonding - multiple interfaces mean multiple numa_nodes, any value > > set here is just as likely to be wrong as right > > > > * mpipe - no real large memory area to associate with a numa node > > > > * virtio - uses iopl for communication, and cannot know its numa_node > > > > * vmxnet3 - same concept as virtio > > > > * xenvirt - same as vmxnet3 > > > > I think its better that you store numa locality information in a pmd's > > private bus data, and export it to applications via a device method. > > that provides the flexibility to tell the application that there is no > > numa locality for a device (by not implementing the method), without > > having to expose an unset data field to the application. > > > > Neil > > > > Sure, that could work. > However, is it really worthwhile asking drivers to implement a new ethdev > API function, rather than just having them set the numa node field correctly > in the init function? > > /Bruce The four fields below have been added to struct rte_eth_dev_data uint32_t dev_flags; /**< Flags controlling handling of device. */ enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ int numa_node; const char *drv_name; The data for these fields is available in the struct rte_pci_device. In order to remove the pci_device from the vdev PMD's this data needs to be available in the eth_dev. A new function rte_eth_copy_dev_info() has been added to the eth_dev for use by the pdevs to copy this data from the pci_device to the ethdev. In the vdevs the pci_device has been removed and the new fields are set up directly in the rte_driver.init function. The numa_node is already initialised in the following vdev PMD's: af_packet - initialized from socket_id bonding - initialized from socket_id mpipe - initialized from instance null - initialized from socket_id pcap - initialized from socket_id ring - initialized form socket_id xenvirt - initialized from socket_id Regards, Bernard.
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index b309309..e4cb285 100644 --- a/lib/librte_ether/rte_ethdev.c +++ b/lib/librte_ether/rte_ethdev.c @@ -424,7 +424,7 @@ rte_eth_dev_socket_id(uint8_t port_id) { if (!rte_eth_dev_is_valid_port(port_id)) return -1; - return rte_eth_devices[port_id].pci_dev->numa_node; + return rte_eth_devices[port_id].data->numa_node; } uint8_t @@ -503,27 +503,25 @@ rte_eth_dev_get_name_by_port(uint8_t port_id, char *name) static int rte_eth_dev_is_detachable(uint8_t port_id) { - uint32_t drv_flags; + uint32_t dev_flags; if (!rte_eth_dev_is_valid_port(port_id)) { PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id); return -EINVAL; } - if (rte_eth_devices[port_id].dev_type == RTE_ETH_DEV_PCI) { - switch (rte_eth_devices[port_id].pci_dev->kdrv) { - case RTE_KDRV_IGB_UIO: - case RTE_KDRV_UIO_GENERIC: - case RTE_KDRV_NIC_UIO: - break; - case RTE_KDRV_VFIO: - default: - return -ENOTSUP; - } + switch (rte_eth_devices[port_id].data->kdrv) { + case RTE_KDRV_IGB_UIO: + case RTE_KDRV_UIO_GENERIC: + case RTE_KDRV_NIC_UIO: + case RTE_KDRV_NONE: + break; + case RTE_KDRV_VFIO: + default: + return -ENOTSUP; } - - drv_flags = rte_eth_devices[port_id].driver->pci_drv.drv_flags; - return !(drv_flags & RTE_PCI_DRV_DETACHABLE); + dev_flags = rte_eth_devices[port_id].data->dev_flags; + return !(dev_flags & RTE_ETH_DEV_DETACHABLE); } /* attach the new physical device, then store port_id of the device */ @@ -1143,14 +1141,11 @@ rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q, * If link state interrupt is enabled, check that the * device supports it. */ - if (dev_conf->intr_conf.lsc == 1) { - const struct rte_pci_driver *pci_drv = &dev->driver->pci_drv; - - if (!(pci_drv->drv_flags & RTE_PCI_DRV_INTR_LSC)) { + if ((dev_conf->intr_conf.lsc == 1) && + (!(dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC))) { PMD_DEBUG_TRACE("driver %s does not support lsc\n", - pci_drv->name); + dev->data->drv_name); return -EINVAL; - } } /* @@ -1795,8 +1790,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info) FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get); (*dev->dev_ops->dev_infos_get)(dev, dev_info); dev_info->pci_dev = dev->pci_dev; - if (dev->driver) - dev_info->driver_name = dev->driver->pci_drv.name; + dev_info->driver_name = dev->data->drv_name; } void @@ -3570,3 +3564,16 @@ rte_eth_dev_set_eeprom(uint8_t port_id, struct rte_dev_eeprom_info *info) FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_eeprom, -ENOTSUP); return (*dev->dev_ops->set_eeprom)(dev, info); } + +void +rte_eth_copy_dev_info(struct rte_eth_dev *eth_dev, struct rte_pci_device *pci_dev) +{ + if ((eth_dev == NULL) || (pci_dev == NULL)) + PMD_DEBUG_TRACE("NULL pointer eth_dev=%p pci_dev=%p\n", + eth_dev, pci_dev); + + eth_dev->data->dev_flags = pci_dev->driver->drv_flags; + eth_dev->data->kdrv = pci_dev->kdrv; + eth_dev->data->numa_node = pci_dev->numa_node; + eth_dev->data->drv_name = pci_dev->driver->name; +} diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h index fa06554..9cd262b 100644 --- a/lib/librte_ether/rte_ethdev.h +++ b/lib/librte_ether/rte_ethdev.h @@ -1635,8 +1635,23 @@ struct rte_eth_dev_data { all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */ dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */ lro : 1; /**< RX LRO is ON(1) / OFF(0) */ + uint32_t dev_flags; /**< Flags controlling handling of device. */ + enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */ + int numa_node; + const char *drv_name; }; +/** Device needs PCI BAR mapping (done with either IGB_UIO or VFIO) */ +#define RTE_ETH_DEV_DRV_NEED_MAPPING RTE_PCI_DRV_NEED_MAPPING +/** Device needs to be unbound even if no module is provided */ +#define RTE_ETH_DEV_DRV_FORCE_UNBIND RTE_PCI_DRV_FORCE_UNBIND +/** Device supports link state interrupt */ +#define RTE_ETH_DEV_INTR_LSC RTE_PCI_DRV_INTR_LSC +/** Device supports detaching capability */ +#define RTE_ETH_DEV_DETACHABLE RTE_PCI_DRV_DETACHABLE +/** Device is a bonded device */ +#define RTE_ETH_DEV_BONDED 0x0020 + /** * @internal * The pool of *rte_eth_dev* structures. The size of the pool
add dev_flags to rte_eth_dev_data, add macros for dev_flags. add kdrv to rte_eth_dev_data. add numa_node to rte_eth_dev_data. add drv_name to rte_eth_dev_data. use dev_type to distinguish between vdev's and pdev's. remove pci_dev branches. Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com> --- lib/librte_ether/rte_ethdev.c | 53 ++++++++++++++++++++++++------------------- lib/librte_ether/rte_ethdev.h | 15 ++++++++++++ 2 files changed, 45 insertions(+), 23 deletions(-)