From: Chaoyong He <chaoyong.he@corigine.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: oss-drivers <oss-drivers@corigine.com>,
Niklas Soderlund <niklas.soderlund@corigine.com>,
Walter Heymans <walter.heymans@corigine.com>
Subject: RE: [PATCH v2 2/3] doc: update outdated information for the nfp PMD
Date: Tue, 21 Feb 2023 10:11:42 +0000 [thread overview]
Message-ID: <SJ0PR13MB554535D856C180E0729DCA919EA59@SJ0PR13MB5545.namprd13.prod.outlook.com> (raw)
In-Reply-To: <58d6df9a-4f4d-b911-a08a-d13e3688f23e@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?
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.
next prev parent reply other threads:[~2023-02-21 10:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 8:08 [PATCH] doc: update NFP documentation with Corigine information Chaoyong He
2023-02-15 13:37 ` Ferruh Yigit
2023-02-15 17:58 ` Niklas Söderlund
2023-02-20 8:41 ` [PATCH v2 0/3] update NFP documentation Chaoyong He
2023-02-20 8:41 ` [PATCH v2 1/3] doc: wrap nfp doc to 80 characters and improve grammar Chaoyong He
2023-02-20 8:41 ` [PATCH v2 2/3] doc: update outdated information for the nfp PMD Chaoyong He
2023-02-20 12:25 ` Ferruh Yigit
2023-02-21 9:04 ` Chaoyong He
2023-02-21 9:29 ` Ferruh Yigit
2023-02-21 10:11 ` Chaoyong He [this message]
2023-02-21 10:42 ` Ferruh Yigit
2023-02-20 8:41 ` [PATCH v2 3/3] doc: add Corigine information to nfp documentation Chaoyong He
2023-02-22 1:23 ` [PATCH v2 0/3] update NFP documentation Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SJ0PR13MB554535D856C180E0729DCA919EA59@SJ0PR13MB5545.namprd13.prod.outlook.com \
--to=chaoyong.he@corigine.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=niklas.soderlund@corigine.com \
--cc=oss-drivers@corigine.com \
--cc=walter.heymans@corigine.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).