| Message ID | 1614868228-13685-8-git-send-email-xuemingl@nvidia.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Ferruh Yigit |
| Headers | show |
| Series | ethdev: support SubFunction representor | expand |
| Context | Check | Description |
|---|---|---|
| ci/checkpatch | success | coding style OK |
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.
diff --git a/lib/librte_ethdev/ethdev_driver.h b/lib/librte_ethdev/ethdev_driver.h index 06ff35266f..36e866aa03 100644 --- a/lib/librte_ethdev/ethdev_driver.h +++ b/lib/librte_ethdev/ethdev_driver.h @@ -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. */ }; /** diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c index 60889a8663..3d4ec8ad5c 100644 --- a/lib/librte_ethdev/rte_ethdev.c +++ b/lib/librte_ethdev/rte_ethdev.c @@ -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) diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h index 9cd519bf59..9c7a80c9b5 100644 --- a/lib/librte_ethdev/rte_ethdev.h +++ b/lib/librte_ethdev/rte_ethdev.h @@ -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> /** diff --git a/lib/librte_ethdev/version.map b/lib/librte_ethdev/version.map index a124e1e370..bb6f7436c2 100644 --- a/lib/librte_ethdev/version.map +++ b/lib/librte_ethdev/version.map @@ -243,6 +243,9 @@ EXPERIMENTAL { # added in 21.02 rte_eth_get_monitor_addr; + + # added in 21.05 + rte_eth_representor_info_get; }; INTERNAL {