[v4] ethdev: fix representor port ID search by name
Checks
Commit Message
From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Getting a list of representors from a representor does not make sense.
Instead, a parent device should be used.
To this end, extend the rte_eth_dev_data structure to include the port ID
of the backing device for representors.
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
The new field is added into the hole in rte_eth_dev_data structure.
The patch does not change ABI, but extra care is required since ABI
check is disabled for the structure because of the libabigail bug [1].
Potentially it is bad for out-of-tree drivers which implement
representors but do not fill in a new parert_port_id field in
rte_eth_dev_data structure. Do we care?
mlx5 changes should be reviwed by maintainers very carefully, since
we are not sure if we patch it correctly.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
v4:
- apply mlx5 review notes: remove fallback from generic ethdev
code and add fallback to mlx5 code to handle legacy usecase
v3:
- fix mlx5 build breakage
v2:
- fix mlx5 review notes
- try device port ID first before parent in order to address
backward compatibility issue
drivers/net/bnxt/bnxt_reps.c | 1 +
drivers/net/enic/enic_vf_representor.c | 1 +
drivers/net/i40e/i40e_vf_representor.c | 1 +
drivers/net/ice/ice_dcf_vf_representor.c | 1 +
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
lib/ethdev/ethdev_driver.h | 6 +++---
lib/ethdev/rte_class_eth.c | 2 +-
lib/ethdev/rte_ethdev.c | 8 ++++----
lib/ethdev/rte_ethdev_core.h | 6 ++++++
11 files changed, 45 insertions(+), 8 deletions(-)
Comments
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Wednesday, September 1, 2021 00:06
> To: Ajit Khaparde <ajit.khaparde@broadcom.com>; Somnath Kotur <somnath.kotur@broadcom.com>; Daley,
> John <johndale@cisco.com>; Hyong Youb Kim <hyonkim@cisco.com>; Xing, Beilei <beilei.xing@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>; Matan Azrad <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>;
> Viacheslav Ovsiienko <viacheslavo@nvidia.com>; Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> Subject: [PATCH v4] ethdev: fix representor port ID search by name
>
> From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>
> Getting a list of representors from a representor does not make sense.
> Instead, a parent device should be used.
>
> To this end, extend the rte_eth_dev_data structure to include the port ID
> of the backing device for representors.
>
> Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> ---
> The new field is added into the hole in rte_eth_dev_data structure.
> The patch does not change ABI, but extra care is required since ABI
> check is disabled for the structure because of the libabigail bug [1].
>
> Potentially it is bad for out-of-tree drivers which implement
> representors but do not fill in a new parert_port_id field in
> rte_eth_dev_data structure. Do we care?
Set the `parent_port_id` to ' RTE_MAX_ETHPORTS' as an invalid port ID
in rte_eth_dev_allocate ?
>
> mlx5 changes should be reviwed by maintainers very carefully, since
> we are not sure if we patch it correctly.
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
>
> v4:
> - apply mlx5 review notes: remove fallback from generic ethdev
> code and add fallback to mlx5 code to handle legacy usecase
>
> v3:
> - fix mlx5 build breakage
>
> v2:
> - fix mlx5 review notes
> - try device port ID first before parent in order to address
> backward compatibility issue
>
> drivers/net/bnxt/bnxt_reps.c | 1 +
> drivers/net/enic/enic_vf_representor.c | 1 +
> drivers/net/i40e/i40e_vf_representor.c | 1 +
> drivers/net/ice/ice_dcf_vf_representor.c | 1 +
> drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
> drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
> drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
> lib/ethdev/ethdev_driver.h | 6 +++---
> lib/ethdev/rte_class_eth.c | 2 +-
> lib/ethdev/rte_ethdev.c | 8 ++++----
> lib/ethdev/rte_ethdev_core.h | 6 ++++++
> 11 files changed, 45 insertions(+), 8 deletions(-)
>
For ixgbe_vf, ice_dcf
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
> --
> 2.30.2
On 8/31/21 7:32 PM, Wang, Haiyue wrote:
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Wednesday, September 1, 2021 00:06
>> To: Ajit Khaparde <ajit.khaparde@broadcom.com>; Somnath Kotur <somnath.kotur@broadcom.com>; Daley,
>> John <johndale@cisco.com>; Hyong Youb Kim <hyonkim@cisco.com>; Xing, Beilei <beilei.xing@intel.com>;
>> Yang, Qiming <qiming.yang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wang, Haiyue
>> <haiyue.wang@intel.com>; Matan Azrad <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>;
>> Viacheslav Ovsiienko <viacheslavo@nvidia.com>; Thomas Monjalon <thomas@monjalon.net>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>
>> Cc: dev@dpdk.org; Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>> Subject: [PATCH v4] ethdev: fix representor port ID search by name
>>
>> From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>>
>> Getting a list of representors from a representor does not make sense.
>> Instead, a parent device should be used.
>>
>> To this end, extend the rte_eth_dev_data structure to include the port ID
>> of the backing device for representors.
>>
>> Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> ---
>> The new field is added into the hole in rte_eth_dev_data structure.
>> The patch does not change ABI, but extra care is required since ABI
>> check is disabled for the structure because of the libabigail bug [1].
>>
>> Potentially it is bad for out-of-tree drivers which implement
>> representors but do not fill in a new parert_port_id field in
>> rte_eth_dev_data structure. Do we care?
>
> Set the `parent_port_id` to ' RTE_MAX_ETHPORTS' as an invalid port ID
> in rte_eth_dev_allocate ?
I like the idea. It should be safer this way. Many thanks.
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Wednesday, September 1, 2021 12:06 AM
> To: Ajit Khaparde <ajit.khaparde@broadcom.com>; Somnath Kotur
> <somnath.kotur@broadcom.com>; Daley, John <johndale@cisco.com>;
> Hyong Youb Kim <hyonkim@cisco.com>; Xing, Beilei <beilei.xing@intel.com>;
> Yang, Qiming <qiming.yang@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
> Wang, Haiyue <haiyue.wang@intel.com>; Matan Azrad
> <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>; Viacheslav
> Ovsiienko <viacheslavo@nvidia.com>; Thomas Monjalon
> <thomas@monjalon.net>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Cc: dev@dpdk.org; Viacheslav Galaktionov
> <viacheslav.galaktionov@oktetlabs.ru>
> Subject: [PATCH v4] ethdev: fix representor port ID search by name
>
> From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>
> Getting a list of representors from a representor does not make sense.
> Instead, a parent device should be used.
>
> To this end, extend the rte_eth_dev_data structure to include the port ID of
> the backing device for representors.
>
> Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> ---
> The new field is added into the hole in rte_eth_dev_data structure.
> The patch does not change ABI, but extra care is required since ABI check is
> disabled for the structure because of the libabigail bug [1].
>
> Potentially it is bad for out-of-tree drivers which implement representors but
> do not fill in a new parert_port_id field in rte_eth_dev_data structure. Do we
> care?
>
> mlx5 changes should be reviwed by maintainers very carefully, since we are
> not sure if we patch it correctly.
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
>
> v4:
> - apply mlx5 review notes: remove fallback from generic ethdev
> code and add fallback to mlx5 code to handle legacy usecase
>
> v3:
> - fix mlx5 build breakage
>
> v2:
> - fix mlx5 review notes
> - try device port ID first before parent in order to address
> backward compatibility issue
>
> drivers/net/bnxt/bnxt_reps.c | 1 +
> drivers/net/enic/enic_vf_representor.c | 1 +
> drivers/net/i40e/i40e_vf_representor.c | 1 +
> drivers/net/ice/ice_dcf_vf_representor.c | 1 +
> drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
> drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
> drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
> lib/ethdev/ethdev_driver.h | 6 +++---
> lib/ethdev/rte_class_eth.c | 2 +-
> lib/ethdev/rte_ethdev.c | 8 ++++----
> lib/ethdev/rte_ethdev_core.h | 6 ++++++
> 11 files changed, 45 insertions(+), 8 deletions(-)
>
For i40e part,
Acked-by: Beilei Xing <beilei.xing@intel.com>
On 8/31/2021 5:06 PM, Andrew Rybchenko wrote:
> From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>
> Getting a list of representors from a representor does not make sense.
> Instead, a parent device should be used.
>
Which code is getting list of the representors?
As far as I can see impacted APIs are:
'rte_eth_representor_id_get()'
'rte_eth_representor_info_get()'
Which are now getting 'parent_port_id' as argument, instead of representro port id.
'rte_eth_representor_info_get()' is using 'representor_info_get()' dev_ops,
which is only implemented by 'mlx5', so is this problem only valid for 'mlx5'
and can it be solved within PMD implementation?
> To this end, extend the rte_eth_dev_data structure to include the port ID
> of the backing device for representors.
>
> Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> ---
> The new field is added into the hole in rte_eth_dev_data structure.
> The patch does not change ABI, but extra care is required since ABI
> check is disabled for the structure because of the libabigail bug [1].
>
> Potentially it is bad for out-of-tree drivers which implement
> representors but do not fill in a new parert_port_id field in
> rte_eth_dev_data structure. Do we care?
>
> mlx5 changes should be reviwed by maintainers very carefully, since
> we are not sure if we patch it correctly.
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
>
> v4:
> - apply mlx5 review notes: remove fallback from generic ethdev
> code and add fallback to mlx5 code to handle legacy usecase
>
> v3:
> - fix mlx5 build breakage
>
> v2:
> - fix mlx5 review notes
> - try device port ID first before parent in order to address
> backward compatibility issue
>
<...>
> index edf96de2dc..72fefa59c2 100644
> --- a/lib/ethdev/rte_ethdev_core.h
> +++ b/lib/ethdev/rte_ethdev_core.h
> @@ -185,6 +185,12 @@ struct rte_eth_dev_data {
> /**< Switch-specific identifier.
> * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
> */
> + uint16_t parent_port_id;
Why 'parent'? Isn't this for the port that port representator represents, does
it called 'parent'? Above that device mentioned as 'backing device' a few times,
so would something like 'peer_port_id' better?
> + /**< Port ID of the backing device.
> + * This device will be used to query representor
> + * info and calculate representor IDs.
> + * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
> + */
>
Overall I am not feeling good about adding representor port related information
withing the device data struct.
I wonder if this information can be kept in the device private data.
Or, it is hard to explain but can we use something like inheritance, a
representor specific dev_data derived from original dev_data. We can store
dev_data pointers in 'struct rte_eth_dev' but can cast it to representor
specific dev_data when type is representor.
struct rte_eth_dev_data_rep
struct rte_eth_dev_data
<representor specific fields>
This brings lots of complexity though, specially in allocating/freeing this
struct, not sure if it worth to the effort.
On 2021-09-01 17:55, Ferruh Yigit wrote:
> On 8/31/2021 5:06 PM, Andrew Rybchenko wrote:
>> From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
>>
>> Getting a list of representors from a representor does not make sense.
>> Instead, a parent device should be used.
>>
>
> Which code is getting list of the representors?
>
> As far as I can see impacted APIs are:
> 'rte_eth_representor_id_get()'
> 'rte_eth_representor_info_get()'
>
> Which are now getting 'parent_port_id' as argument, instead of
> representro port id.
>
> 'rte_eth_representor_info_get()' is using 'representor_info_get()'
> dev_ops,
> which is only implemented by 'mlx5', so is this problem only valid for
> 'mlx5'
> and can it be solved within PMD implementation?
It's not an mlx5-specific problem, it's going to affect sfc as well once
it
starts supporting representors. But that doesn't really matter as it's
more
about the usage of representors in general, not specific to any PMD's
internals.
Since representors are created through some device (which is probed and
assigned
a port ID), it makes sense to query the list of representors from the
same
device.
[snip]
>> index edf96de2dc..72fefa59c2 100644
>> --- a/lib/ethdev/rte_ethdev_core.h
>> +++ b/lib/ethdev/rte_ethdev_core.h
>> @@ -185,6 +185,12 @@ struct rte_eth_dev_data {
>> /**< Switch-specific identifier.
>> * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
>> */
>> + uint16_t parent_port_id;
>
> Why 'parent'? Isn't this for the port that port representator
> represents, does
> it called 'parent'? Above that device mentioned as 'backing device' a
> few times,
> so would something like 'peer_port_id' better?
This is true, the naming here is confusing and should be changed.
"parent_port_id" doesn't point at the represented entity, but at the
device
that was used to create this representor. We call it the backing device,
so
using "backer_port_id" sounds appropriate, what do you think?
>> + /**< Port ID of the backing device.
>> + * This device will be used to query representor
>> + * info and calculate representor IDs.
>> + * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
>> + */
>>
>
>
> Overall I am not feeling good about adding representor port related
> information
> withing the device data struct.
> I wonder if this information can be kept in the device private data.
>
> Or, it is hard to explain but can we use something like inheritance, a
> representor specific dev_data derived from original dev_data. We can
> store
> dev_data pointers in 'struct rte_eth_dev' but can cast it to
> representor
> specific dev_data when type is representor.
>
> struct rte_eth_dev_data_rep
> struct rte_eth_dev_data
> <representor specific fields>
>
> This brings lots of complexity though, specially in allocating/freeing
> this
> struct, not sure if it worth to the effort.
This information is usually kept in the device private data as well, but
we
need to use it from the generic code to redirect the representor info
requests
to the appropriate ports.
Using "inheritance" is a good suggestion, but it does bring a lot of
complexity,
as you've said, and we're not sure if the result is worth the effort.
We can also avoid storing this port ID in the device data by creating a
special
callback that PMDs would use to return it. However, this also brings
complexity
and this information is static anyway, so having a separate callback
might be
a little too much.
What we're doing here just seems to be the simplest option.
@@ -187,6 +187,7 @@ int bnxt_representor_init(struct rte_eth_dev *eth_dev, void *params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = rep_params->vf_id;
+ eth_dev->data->parent_port_id = rep_params->parent_dev->data->port_id;
rte_eth_random_addr(vf_rep_bp->dflt_mac_addr);
memcpy(vf_rep_bp->mac_addr, vf_rep_bp->dflt_mac_addr,
@@ -662,6 +662,7 @@ int enic_vf_representor_init(struct rte_eth_dev *eth_dev, void *init_params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = vf->vf_id;
+ eth_dev->data->parent_port_id = pf->port_id;
eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr_vf",
sizeof(struct rte_ether_addr) *
ENIC_UNICAST_PERFECT_FILTERS, 0);
@@ -514,6 +514,7 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->parent_port_id = pf->dev_data->port_id;
/* Setting the number queues allocated to the VF */
ethdev->data->nb_rx_queues = vf->vsi->nb_qps;
@@ -418,6 +418,7 @@ ice_dcf_vf_repr_init(struct rte_eth_dev *vf_rep_eth_dev, void *init_param)
vf_rep_eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
vf_rep_eth_dev->data->representor_id = repr->vf_id;
+ vf_rep_eth_dev->data->parent_port_id = repr->dcf_eth_dev->data->port_id;
vf_rep_eth_dev->data->mac_addrs = &repr->mac_addr;
@@ -197,6 +197,7 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->parent_port_id = representor->pf_ethdev->data->port_id;
/* Set representor device ops */
ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
@@ -1677,6 +1677,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, &priv->pci_dev->device) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->parent_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->parent_port_id = eth_dev->data->port_id;
}
priv->mp_id.port_id = eth_dev->data->port_id;
strlcpy(priv->mp_id.name, MLX5_MP_NAME, RTE_MP_MAX_NAME_LEN);
@@ -543,6 +543,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, &priv->pci_dev->device) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->parent_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->parent_port_id = eth_dev->data->port_id;
}
/*
* Store associated network device interface index. This index
@@ -1248,8 +1248,8 @@ struct rte_eth_devargs {
* For backward compatibility, if no representor info, direct
* map legacy VF (no controller and pf).
*
- * @param ethdev
- * Handle of ethdev port.
+ * @param port_id
+ * Port ID of the backing device.
* @param type
* Representor type.
* @param controller
@@ -1266,7 +1266,7 @@ struct rte_eth_devargs {
*/
__rte_internal
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id);
@@ -95,7 +95,7 @@ eth_representor_cmp(const char *key __rte_unused,
c = i / (np * nf);
p = (i / nf) % np;
f = i % nf;
- if (rte_eth_representor_id_get(edev,
+ if (rte_eth_representor_id_get(edev->data->parent_port_id,
eth_da.type,
eth_da.nb_mh_controllers == 0 ? -1 :
eth_da.mh_controllers[c],
@@ -5997,7 +5997,7 @@ rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs *eth_da)
}
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id)
@@ -6013,7 +6013,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
return -EINVAL;
/* Get PMD representor range info. */
- ret = rte_eth_representor_info_get(ethdev->data->port_id, NULL);
+ ret = rte_eth_representor_info_get(port_id, NULL);
if (ret == -ENOTSUP && type == RTE_ETH_REPRESENTOR_VF &&
controller == -1 && pf == -1) {
/* Direct mapping for legacy VF representor. */
@@ -6028,7 +6028,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
if (info == NULL)
return -ENOMEM;
info->nb_ranges_alloc = n;
- ret = rte_eth_representor_info_get(ethdev->data->port_id, info);
+ ret = rte_eth_representor_info_get(port_id, info);
if (ret < 0)
goto out;
@@ -6047,7 +6047,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
continue;
if (info->ranges[i].id_end < info->ranges[i].id_base) {
RTE_LOG(WARNING, EAL, "Port %hu invalid representor ID Range %u - %u, entry %d\n",
- ethdev->data->port_id, info->ranges[i].id_base,
+ port_id, info->ranges[i].id_base,
info->ranges[i].id_end, i);
continue;
@@ -185,6 +185,12 @@ struct rte_eth_dev_data {
/**< Switch-specific identifier.
* Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
*/
+ uint16_t parent_port_id;
+ /**< Port ID of the backing device.
+ * This device will be used to query representor
+ * info and calculate representor IDs.
+ * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
+ */
pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
uint64_t reserved_64s[4]; /**< Reserved for future fields */