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