DPDK usage discussions
 help / color / mirror / Atom feed
From: Nandini Rangaswamy <nandini.rangaswamy@broadcom.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: users@dpdk.org, longli@microsoft.com
Subject: Re: Query regarding netvsc PMD : VF removal
Date: Fri, 26 Jul 2024 15:45:57 -0700	[thread overview]
Message-ID: <CAAkQrK8Rsg2y+JWmKxUrVR6is5osrx-8BtRWezG-gKD7s0mseA@mail.gmail.com> (raw)
In-Reply-To: <20240725145243.740c20d9@hermes.local>


[-- Attachment #1.1: Type: text/plain, Size: 2940 bytes --]

Hi Stephen and Long,
I am trying to understand the complete packet path and I am confused here.
The synthetic device is being created and managed by a driver in guest
kernel space.
Shouldn't the packets be directly DMAed from NIC to VFs in guest. If all
packets go through synthetic interface to the VF, then wouldn't kernel get
involved here and defeat the purpose of DPDK ?
Please find attached a block diagram that i came up with highlights the
devices and drivers and my understanding of their interactions.
I have shown in the diagram that for every VNIC , a synthetic and VF is
present . Synthetic interfaces are managed by uio_hv_generic and VFs that
appear as PCI devices in the guest kernel are managed by MLNX.
I have also shown that netvsc pmd depends on uio_hv_generic module. The red
arrow represents synthetic data path and green arrows represent the
accelerated data path.
I am still unclear about pkt flow from NIC to VF through synthetic
interface and vice-versa involving netvsc pmd, mlnx driver/PMD.
Can you please clarify this?
Regards,
Nandini


On Thu, Jul 25, 2024 at 2:52 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Thu, 25 Jul 2024 11:41:59 -0700
> Nandini Rangaswamy <nandini.rangaswamy@broadcom.com> wrote:
>
> > Hi Stephen,
> > I am using the DPDK 22.11.5 LTS. Should the DPDK code take care of
> > unbinding synthetic interface from uio_hv_generic or should it be done by
> > the app when it gets hotplug notification?
> > Regards,
> > Nandini
>
> The synthetic device (netvsc) controlled by uio_hv_generic is never hot
> plugged.
> Only the VF which is mlx device can be removed and added.
> The management of the VF for traffic is handled completely internally to
> the netvsc device (same as the Linux netdevice). What happens is the
> host notifys the guest over vmbus when VF changes. For devices handled
> by the DPDK (netvsc PMD), this notification causes it to add/remove use
> of the VF.
>
> The VF should not be used directly. The synthetic device (netvsc) routes
> traffic over the VF and reads from it when it is present and up.
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

[-- Attachment #1.2: Type: text/html, Size: 3525 bytes --]

[-- Attachment #2: Screenshot 2024-07-26 at 3.40.44 PM.png --]
[-- Type: image/png, Size: 278264 bytes --]

  reply	other threads:[~2024-07-26 22:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25 17:52 Nandini Rangaswamy
2024-07-25 18:11 ` Stephen Hemminger
2024-07-25 18:41   ` Nandini Rangaswamy
2024-07-25 21:52     ` Stephen Hemminger
2024-07-26 22:45       ` Nandini Rangaswamy [this message]
2024-07-27  1:14         ` Long Li
2024-08-05 21:52           ` Nandini Rangaswamy

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=CAAkQrK8Rsg2y+JWmKxUrVR6is5osrx-8BtRWezG-gKD7s0mseA@mail.gmail.com \
    --to=nandini.rangaswamy@broadcom.com \
    --cc=longli@microsoft.com \
    --cc=stephen@networkplumber.org \
    --cc=users@dpdk.org \
    /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).