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

[Chaoyong He <chaoyong.he@corigine.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?
 
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.

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

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