Re: [PATCH v2 2/3] doc: update outdated information for the nfp PMD

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 2/21/2023 9:04 AM, Chaoyong He wrote:
>> On 2/20/2023 8:41 AM, Chaoyong He wrote:
>>> From: Walter Heymans <walter.heymans@corigine.com>
>>>
>>> Update nfp documentation with new information and remove outdated
>>> information. The most significant changes that are updated include:
>>> - Previously the NFP PMD did not support functionality to control VFs,
>>>   it now does.
>>
>> What I understand is DPDK supports VF but if PF is bound to Linux driver.
>>
>> Previously support matrix was as following:
>>
>>     PF        VF          is supported
>>   -----      ----        --------------
>>   Linux      DPDK         Yes
>>   DPDK        -           Yes
>>   DPDK       DPDK         NO
>>   DPDK       Linux        ?No (not recommended)
>>
>>
>> Is PF:DPDK, VF:DPDK supported now?
>> This requires DPDK PF driver updated to manage VFs, if so can you please list
>> commits that adds this support in this commit log?
> 
> Yes, we support this mode now.
> But actually, our PMD didn't do anything to support it.
> After the VFIO module in kernel has support vf (not sure about the exact kernel version import this), we can directly use the command below to support this mode.
> modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
> dpdk-devbind.py -b vfio-pci xx:yy.z
> echo 2 > /sys/bus/pci/devices/0000\:xx\:yy.z/sriov_numvfs
> And we get this information first time in this link: https://lwn.net/Articles/813045/
> 

Ability to create VF via vfio-pci is one thing, as you said that support
is added unrelated to the driver.

Other thing is PF driver's capability to manage VFs, since not all
operations are supported by VF driver, sometimes VF driver sends a
request to PF driver for this, so PF should have capability to receive
and handle these requests. Is your driver working in similar way?

Following documentation is from previous version (that this set removes):
"
...
Future DPDK versions will have a PMD able to work with the PF and VFs at
the same time and with the PF implementing VF management along with
other PF-only functionalities/offloads.
"

I was expecting some code changes are required for above mentioned "PF
implementing VF management", are they done already? If so while removing
that part of the documentation it can be good to document commit IDs of
those changes.


And more directly, right now, do you support to run dpdk application on
top of both PF and VF at the *same* time?


>>
>>> - Previously the PF had to be bound to the kernel driver to create VFs,
>>>   then VFs were created and bound to 'vfio-pci'. Currently it is
>>>   possible to bind the PF to 'vfio-pci' and create VFs bound to
>>>   'vfio-pci'.
>>> - The name of the Linux kernel driver changed for VFs. Previously the
>>>   'nfp_netvf' module was used, but now both PFs and VFs use the 'nfp'
>>>   module.
>>>
>>> Signed-off-by: Walter Heymans <walter.heymans@corigine.com>
>>> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
>>> Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
>>
>> <...>
>>
>>> @@ -209,8 +207,8 @@ vNIC service will keep polling packets from the
>>> firmware, and multiplex them  to the corresponding representor port.
>>>
>>>  In the Tx direction, the representor port will prepend the output
>>> port -information into metadata for each packet, and then send it to
>>> firmware through -PF vNIC.
>>> +information into metadata for each packet, and then send it to the
>>> +firmware through the PF vNIC.
>>>
>>
>> Above change belongs to first patch.
> 
> Thanks, we will move it in the next version.