>-----Original Message-----
>From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
>Sent: Tuesday, January 19, 2021 4:06 PM
>To: Xueming(Steven) Li <xuemi...@nvidia.com>
>Cc: dev@dpdk.org; Slava Ovsiienko <viachesl...@nvidia.com>; Asaf Penso
><as...@nvidia.com>; NBU-Contact-Thomas Monjalon
><tho...@monjalon.net>; Ferruh Yigit <ferruh.yi...@intel.com>
>Subject: Re: [PATCH v5 8/9] ethdev: add capability of sub-function representor
>
>On 1/19/21 10:15 AM, Xueming Li wrote:
>> Old DPDK version or some drivers didn't support SubFunction representor.
>> For application to adapt different DPDK version automatically, or to
>> be used for different NICs, this patch introduces new eth device
>> capability of supporting SubFunction representor device.
>
>Sorry, it does not sound sufficient motivation to introduce the capability. I
>simply need real life example why application need to know it.
I had same internal discussion on this as well :)
A simple example, for customer running DPDK based app with NICs from different
vendors,
app need a flag to know whether the device support SF representor, hotplug SF
if the
capability shows "support". This also happens with different model/fw even from
same vendor.
PMD report device+driver capability that whether SF supported.
>
>> Signed-off-by: Xueming Li <xuemi...@nvidia.com>
>> Acked-by: Viacheslav Ovsiienko <viachesl...@nvidia.com>
>> Acked-by: Thomas Monjalon <tho...@monjalon.net>
>> ---
>> lib/librte_ethdev/rte_ethdev.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h
>> b/lib/librte_ethdev/rte_ethdev.h index 2cbce958cf..da65adf1ab 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -1433,6 +1433,8 @@ struct rte_eth_conf { #define
>> RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP 0x00000001
>> /** Device supports Tx queue setup after device started. */ #define
>> RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP 0x00000002
>> +/** Device supports SubFunction representor. */
>> +#define RTE_ETH_DEV_CAPA_REPRESENTOR_SF 0x00000004
>
>Will we have a PMD which supports it in the release cycle?
Please see reply above, it also reflect device hw capability.
>
>> /**@}*/
>>
>> /*
