[v8,7/9] ethdev: new API to get representor info
Checks
Commit Message
The NIC can have multiple PCIe links and can be attached to multiple
hosts, for example the same single NIC can be shared for multiple server
units in the rack. On each PCIe link NIC can provide multiple PFs and
VFs/SFs based on these ones. The full representor identifier consists of
three indices - controller index, PF index, and VF or SF index (if any).
This patch introduces a new API rte_eth_representor_info_get() to
retrieve representor corresponding info mapping:
- caller controller index and pf index.
- supported representor ID ranges.
- type, controller, pf and start vf/sf ID of each range.
The API is useful to convert representor from devargs to representor ID.
New ethdev callback representor_info_get() is added to retrieve info
from PMD driver, optional for PMD that doesn't support new devargs
representor syntax.
Signed-off-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
lib/librte_ethdev/ethdev_driver.h | 7 +++++
lib/librte_ethdev/rte_ethdev.c | 14 +++++++++
lib/librte_ethdev/rte_ethdev.h | 51 +++++++++++++++++++++++++++++++
lib/librte_ethdev/version.map | 3 ++
4 files changed, 75 insertions(+)
Comments
On 3/4/2021 2:30 PM, Xueming Li wrote:
> The NIC can have multiple PCIe links and can be attached to multiple
> hosts, for example the same single NIC can be shared for multiple server
> units in the rack. On each PCIe link NIC can provide multiple PFs and
> VFs/SFs based on these ones. The full representor identifier consists of
> three indices - controller index, PF index, and VF or SF index (if any).
>
> This patch introduces a new API rte_eth_representor_info_get() to
> retrieve representor corresponding info mapping:
> - caller controller index and pf index.
> - supported representor ID ranges.
> - type, controller, pf and start vf/sf ID of each range.
> The API is useful to convert representor from devargs to representor ID.
>
> New ethdev callback representor_info_get() is added to retrieve info
> from PMD driver, optional for PMD that doesn't support new devargs
> representor syntax.
>
> Signed-off-by: Xueming Li <xuemingl@nvidia.com>
> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
This is middle layer implementation, and there is not problem with it but
without PMD and application implementations it is harder to get why/how this API
will be used.
As far as I can see this API is not directly needed for this set, what do you
think making this another set with PMD and application implementations on top of
current set?
>-----Original Message-----
>From: Ferruh Yigit <ferruh.yigit@intel.com>
>Sent: Monday, March 8, 2021 10:44 PM
>To: Xueming(Steven) Li <xuemingl@nvidia.com>; Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>; NBU-Contact-Thomas Monjalon
><thomas@monjalon.net>; Ray Kinsella <mdr@ashroe.eu>; Neil Horman <nhorman@tuxdriver.com>
>Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info
>
>On 3/4/2021 2:30 PM, Xueming Li wrote:
>> The NIC can have multiple PCIe links and can be attached to multiple
>> hosts, for example the same single NIC can be shared for multiple
>> server units in the rack. On each PCIe link NIC can provide multiple
>> PFs and VFs/SFs based on these ones. The full representor identifier
>> consists of three indices - controller index, PF index, and VF or SF index (if any).
>>
>> This patch introduces a new API rte_eth_representor_info_get() to
>> retrieve representor corresponding info mapping:
>> - caller controller index and pf index.
>> - supported representor ID ranges.
>> - type, controller, pf and start vf/sf ID of each range.
>> The API is useful to convert representor from devargs to representor ID.
>>
>> New ethdev callback representor_info_get() is added to retrieve info
>> from PMD driver, optional for PMD that doesn't support new devargs
>> representor syntax.
>>
>> Signed-off-by: Xueming Li <xuemingl@nvidia.com>
>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
>This is middle layer implementation, and there is not problem with it but without PMD and application implementations it is harder to
>get why/how this API will be used.
>
>As far as I can see this API is not directly needed for this set, what do you think making this another set with PMD and application
>implementations on top of current set?
Hi Ferruh,
Thanks for checking this! The patch next, 8/9 which update device iterator for SF representor needs this API to get representor ID then compare.
On 3/8/2021 3:31 PM, Xueming(Steven) Li wrote:
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Monday, March 8, 2021 10:44 PM
>> To: Xueming(Steven) Li <xuemingl@nvidia.com>; Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>; NBU-Contact-Thomas Monjalon
>> <thomas@monjalon.net>; Ray Kinsella <mdr@ashroe.eu>; Neil Horman <nhorman@tuxdriver.com>
>> Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info
>>
>> On 3/4/2021 2:30 PM, Xueming Li wrote:
>>> The NIC can have multiple PCIe links and can be attached to multiple
>>> hosts, for example the same single NIC can be shared for multiple
>>> server units in the rack. On each PCIe link NIC can provide multiple
>>> PFs and VFs/SFs based on these ones. The full representor identifier
>>> consists of three indices - controller index, PF index, and VF or SF index (if any).
>>>
>>> This patch introduces a new API rte_eth_representor_info_get() to
>>> retrieve representor corresponding info mapping:
>>> - caller controller index and pf index.
>>> - supported representor ID ranges.
>>> - type, controller, pf and start vf/sf ID of each range.
>>> The API is useful to convert representor from devargs to representor ID.
>>>
>>> New ethdev callback representor_info_get() is added to retrieve info
>>> from PMD driver, optional for PMD that doesn't support new devargs
>>> representor syntax.
>>>
>>> Signed-off-by: Xueming Li <xuemingl@nvidia.com>
>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>
>> This is middle layer implementation, and there is not problem with it but without PMD and application implementations it is harder to
>> get why/how this API will be used.
>>
>> As far as I can see this API is not directly needed for this set, what do you think making this another set with PMD and application
>> implementations on top of current set?
>
> Hi Ferruh,
>
> Thanks for checking this! The patch next, 8/9 which update device iterator for SF representor needs this API to get representor ID then compare.
>
Got it thanks.
Intention of the new API seems to get info to be able to calculate the unique
"representor ID" and the helper function 'rte_eth_representor_id_get()'
implements a logic to calculate this unique ID but that logic is not clear, can
you please document it more to help the PMD developers to implement
'representor_info_get()'?
>-----Original Message-----
>From: Ferruh Yigit <ferruh.yigit@intel.com>
>Sent: Tuesday, March 9, 2021 12:12 AM
>To: Xueming(Steven) Li <xuemingl@nvidia.com>; Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf Penso <asafp@nvidia.com>; NBU-Contact-Thomas Monjalon
><thomas@monjalon.net>; Ray Kinsella <mdr@ashroe.eu>; Neil Horman <nhorman@tuxdriver.com>
>Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info
>
>On 3/8/2021 3:31 PM, Xueming(Steven) Li wrote:
>>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>>> Sent: Monday, March 8, 2021 10:44 PM
>>> To: Xueming(Steven) Li <xuemingl@nvidia.com>; Andrew Rybchenko
>>> <andrew.rybchenko@oktetlabs.ru>
>>> Cc: dev@dpdk.org; Slava Ovsiienko <viacheslavo@nvidia.com>; Asaf
>>> Penso <asafp@nvidia.com>; NBU-Contact-Thomas Monjalon
>>> <thomas@monjalon.net>; Ray Kinsella <mdr@ashroe.eu>; Neil Horman
>>> <nhorman@tuxdriver.com>
>>> Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info
>>>
>>> On 3/4/2021 2:30 PM, Xueming Li wrote:
>>>> The NIC can have multiple PCIe links and can be attached to multiple
>>>> hosts, for example the same single NIC can be shared for multiple
>>>> server units in the rack. On each PCIe link NIC can provide multiple
>>>> PFs and VFs/SFs based on these ones. The full representor identifier
>>>> consists of three indices - controller index, PF index, and VF or SF index (if any).
>>>>
>>>> This patch introduces a new API rte_eth_representor_info_get() to
>>>> retrieve representor corresponding info mapping:
>>>> - caller controller index and pf index.
>>>> - supported representor ID ranges.
>>>> - type, controller, pf and start vf/sf ID of each range.
>>>> The API is useful to convert representor from devargs to representor ID.
>>>>
>>>> New ethdev callback representor_info_get() is added to retrieve info
>>>> from PMD driver, optional for PMD that doesn't support new devargs
>>>> representor syntax.
>>>>
>>>> Signed-off-by: Xueming Li <xuemingl@nvidia.com>
>>>> Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>>>
>>> This is middle layer implementation, and there is not problem with it
>>> but without PMD and application implementations it is harder to get why/how this API will be used.
>>>
>>> As far as I can see this API is not directly needed for this set,
>>> what do you think making this another set with PMD and application implementations on top of current set?
>>
>> Hi Ferruh,
>>
>> Thanks for checking this! The patch next, 8/9 which update device iterator for SF representor needs this API to get representor ID
>then compare.
>>
>
>Got it thanks.
>Intention of the new API seems to get info to be able to calculate the unique "representor ID" and the helper function
>'rte_eth_representor_id_get()'
>implements a logic to calculate this unique ID but that logic is not clear, can you please document it more to help the PMD developers
>to implement 'representor_info_get()'?
Sure, will update.
@@ -783,6 +783,10 @@ typedef int (*eth_hairpin_queue_peer_unbind_t)
typedef int (*eth_get_monitor_addr_t)(void *rxq,
struct rte_power_monitor_cond *pmc);
+typedef int (*eth_representor_info_get_t)(struct rte_eth_dev *dev,
+ struct rte_eth_representor_info *info);
+/**< @internal Get representor type and ID range. */
+
/**
* @internal A structure containing the functions exported by an Ethernet driver.
*/
@@ -940,6 +944,9 @@ struct eth_dev_ops {
eth_get_monitor_addr_t get_monitor_addr;
/**< Get power monitoring condition for Rx queue. */
+
+ eth_representor_info_get_t representor_info_get;
+ /**< Get representor info. */
};
/**
@@ -5816,6 +5816,20 @@ rte_eth_hairpin_queue_peer_unbind(uint16_t cur_port, uint16_t cur_queue,
direction);
}
+int
+rte_eth_representor_info_get(uint16_t port_id,
+ struct rte_eth_representor_info *info)
+{
+ struct rte_eth_dev *dev;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->representor_info_get, -ENOTSUP);
+ return eth_err(port_id, (*dev->dev_ops->representor_info_get)(dev,
+ info));
+}
+
RTE_LOG_REGISTER(rte_eth_dev_logtype, lib.ethdev, INFO);
RTE_INIT(ethdev_init_telemetry)
@@ -4791,6 +4791,57 @@ __rte_experimental
int rte_eth_dev_hairpin_capability_get(uint16_t port_id,
struct rte_eth_hairpin_cap *cap);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice.
+ *
+ * ethernet device representor ID range entry
+ */
+struct rte_eth_representor_range {
+ enum rte_eth_representor_type type; /**< Representor type */
+ int controller; /**< Controller index */
+ int pf; /**< Physical function index */
+ __extension__
+ union {
+ int vf; /**< VF start index */
+ int sf; /**< SF start index */
+ };
+ uint32_t id_base; /**< Representor ID start index */
+ uint32_t id_end; /**< Representor ID end index */
+ char name[RTE_DEV_NAME_MAX_LEN]; /**< Representor name */
+};
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice.
+ *
+ * Ethernet device representor information
+ */
+struct rte_eth_representor_info {
+ uint16_t controller; /**< Controller ID of caller device. */
+ uint16_t pf; /**< Physical function ID of caller device. */
+ struct rte_eth_representor_range ranges[];/**< Representor ID range. */
+};
+
+/**
+ * Retrieve the representor info of the device.
+ *
+ * @param port_id
+ * The port identifier of the device.
+ * @param info
+ * A pointer to a representor info structure.
+ * NULL to return number of range entries and allocate memory
+ * for next call to store detail.
+ * @return
+ * - (-ENOTSUP) if operation is not supported.
+ * - (-ENODEV) if *port_id* invalid.
+ * - (-EIO) if device is removed.
+ * - (>=0) number of representor range entries supported by device.
+ */
+__rte_experimental
+int rte_eth_representor_info_get(uint16_t port_id,
+ struct rte_eth_representor_info *info);
+
#include <rte_ethdev_core.h>
/**
@@ -243,6 +243,9 @@ EXPERIMENTAL {
# added in 21.02
rte_eth_get_monitor_addr;
+
+ # added in 21.05
+ rte_eth_representor_info_get;
};
INTERNAL {