[dpdk-dev,02/20] librte_ether: add fields from rte_pci_driver to rte_eth_dev_data
diff mbox

Message ID 1443445418-18498-3-git-send-email-bernard.iremonger@intel.com
State Superseded, archived
Headers show

Commit Message

Bernard Iremonger Sept. 28, 2015, 1:03 p.m. UTC
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

Neil Horman Sept. 29, 2015, 7:08 p.m. UTC | #1
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
> 
>
Bruce Richardson Sept. 30, 2015, 9:56 a.m. UTC | #2
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
Neil Horman Sept. 30, 2015, 1:14 p.m. UTC | #3
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
Neil Horman Sept. 30, 2015, 1:18 p.m. UTC | #4
> +}
> 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
> 
>
Bruce Richardson Sept. 30, 2015, 1:21 p.m. UTC | #5
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
Bruce Richardson Sept. 30, 2015, 1:23 p.m. UTC | #6
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
Bernard Iremonger Sept. 30, 2015, 4:33 p.m. UTC | #7
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.

Patch
diff mbox

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