[dpdk-dev,02/20] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data
Commit Message
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(-)
Comments
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.
@@ -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;
+}
@@ -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