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

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

On 2/21/2023 10:11 AM, Chaoyong He wrote:
>> 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?
>  
> Our PMD doesn't has a similar way like this.
> The VF either share the same operation function with PF or has a special operation function, or just don't implement the operation at all.
> Maybe in the future we have to add something like this, but for now we don't have that yet.
> 

OK, thanks for clarification. I wasn't sure about it, no more objection
from me.

>> 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.
> How about just drop the modification of this parameter?
> Is that more acceptable?  
> 
>>
>> And more directly, right now, do you support to run dpdk application on top
>> of both PF and VF at the *same* time?
> 
> Yes, we support that, for example, we can run the testpmd app on top of both PF and VF at the same time.
> 

ack

>>
>>>>
>>>>> - 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.
> 

I can proceed with set after this minor change, thanks.