On 1/19/21 2:19 PM, Xueming(Steven) Li wrote: > >> -----Original Message----- >> From: Andrew Rybchenko <[email protected]> >> Sent: Tuesday, January 19, 2021 4:06 PM >> To: Xueming(Steven) Li <[email protected]> >> Cc: [email protected]; Slava Ovsiienko <[email protected]>; Asaf Penso >> <[email protected]>; NBU-Contact-Thomas Monjalon >> <[email protected]>; Ferruh Yigit <[email protected]> >> 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.
Single feature bit is insufficient. Application needs to know how many SF may be used on which PF. >>> Signed-off-by: Xueming Li <[email protected]> >>> Acked-by: Viacheslav Ovsiienko <[email protected]> >>> Acked-by: Thomas Monjalon <[email protected]> [snip]
