On 1/19/21 2:19 PM, Xueming(Steven) Li wrote: > >> -----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.
Single feature bit is insufficient. Application needs to know how many SF may be used on which PF. >>> Signed-off-by: Xueming Li <xuemi...@nvidia.com> >>> Acked-by: Viacheslav Ovsiienko <viachesl...@nvidia.com> >>> Acked-by: Thomas Monjalon <tho...@monjalon.net> [snip]
