From: Patrick Robb <probb@iol.unh.edu>
To: Aaron Conole <aconole@redhat.com>,
Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: Chenbo Xia <chenbox@nvidia.com>, dev <dev@dpdk.org>,
"ci@dpdk.org" <ci@dpdk.org>
Subject: Virtio testing goals for DTS
Date: Tue, 19 Aug 2025 17:48:28 -0400 [thread overview]
Message-ID: <CAJvnSUC58OS+1GqvVgG0ZLCmLXXj3EgibkZ2_oH6EiptuJBm6g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]
Hi Aaron or Maxime,
I want to get your perspective on our testing goals for virtio in DTS if
you are willing.
Dean, who works on DTS, has been running various PVP and PVVP virtio
workloads on one of the SUT servers at UNH, as well as some single VM and
double VM (with inter VM DPDK forwarding) virtio workloads just on his
laptop, so that we can start to get an idea of how we can start validating
DPDK virtio.
We are aware that there is likely a need/desire for us to setup some
vhost-user + virtio testsuites, i.e. there is a tester (traffic gen) server
paired up against a SUT server, the SUT server sets up vhost-user
device(s), creates a VM(s), and creates a virtio-net-pci device which is
connected to the vhost socket from the host, and then we start testpmd in
the VM using the virtio-net-pci device(s). Then we send traffic from the TG
and assess the DPDK behavior inside the virtio VM. Or, we can run the
testpmd inside the VM frontend in tx_only mode and transmit traffic to the
backend vhost testpmd. In any case, these are vhost testplan specific
details which don't really pertain to my real question which is below.
The question I have for you is do you think there would be any benefit to
producing testcases that validating DPDK usage of virtio-net-pci devices in
a VM, but without involving Vhost, and keeping the entire "test"
constrained to a single host. By this I mean, instead of setting up some
vhost/testpmd application on the SUT and forwarding packets from physical
NIC ports to the vhost vdev (which is then accessed by the VM virtio
interfaces), the testcases would involve creating a TAP interface(s) on the
SUT, then making a VM and accessing the TAP interfaces via a virtio
interface in the VM, and then just starting Scapy on the SUT host and
sending traffic at the TAP interfaces, which goes into the VM? This would
mean that the test would not involve any physical devices, but it would
still be validating DPDK Virtio. One reason why this is attractive is that
it would not require particular hardware, I.e. it runs on 1 system and that
system could even be your laptop since it only relies on virtual
interfaces. David had asked about this possibility at Prague, and I think
at that time Maxime piped up to say "and this would also be useful for
virtio" or something like that. Anyhow, let me know if you think this makes
sense or any other thoughts you may have. If it is a reasonable direction
to go in we can start drawing up test plans.
I realize this is kind of a wall of text... happy to discuss at the CI
meeting on Thursday if that is better.
Thanks,
Patrick
[-- Attachment #2: Type: text/html, Size: 2874 bytes --]
next reply other threads:[~2025-08-19 21:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 21:48 Patrick Robb [this message]
2025-08-19 21:49 ` Patrick Robb
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=CAJvnSUC58OS+1GqvVgG0ZLCmLXXj3EgibkZ2_oH6EiptuJBm6g@mail.gmail.com \
--to=probb@iol.unh.edu \
--cc=aconole@redhat.com \
--cc=chenbox@nvidia.com \
--cc=ci@dpdk.org \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.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).