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.heym...@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.heym...@corigine.com> >>>>> Reviewed-by: Chaoyong He <chaoyong...@corigine.com> >>>>> Reviewed-by: Niklas Söderlund <niklas.soderl...@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.
