DPDK CI discussions
 help / color / mirror / Atom feed
From: Patrick Robb <probb@iol.unh.edu>
To: dev <dev@dpdk.org>
Cc: ci@dpdk.org
Subject: DTS WG Meeting Minutes - December 4, 2025
Date: Fri, 12 Dec 2025 14:54:20 -0500	[thread overview]
Message-ID: <CAJvnSUDz1j7H4hgYFHtwTpR593N8=O48_NHi+isKvDK4jSc6ng@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4245 bytes --]

December 4, 2025

Attendees
* Patrick Robb
* Andrew Bailey
* Paul Szczepanek
* Luca Vizzarro

Minutes

General Discussion
* DPDK 25.11 has been released
   * UNH can now begin using the new single_core_foreward test in its CI
testing
   * Patrick to rebase on main, push to for-main
* John McNamera
   * Asking about running testing for the flow rules offload
   * UNH should run the flow suite, share the results back to PMD
maintainers
      * Dean can do this

Patch discussions
* add test case docstring checks to format script
   * Patrick can merge
* Automate loading vfio-pci module:
   *
https://patchwork.dpdk.org/project/dpdk/patch/20251126141650.367633-1-abailey@iol.unh.edu/
   * Patrick to review
* Change default topology to one link:
   *
https://patchwork.dpdk.org/project/dpdk/patch/20251121195511.322005-2-abailey@iol.unh.edu/
   * Andrew has resolved the build error by updating a type hint
   * Patrick to do a review
   * Luca to review as well, and check the function decorator signature
* Extending Flow Offload Testing:
   * For the extended flow offload testing, we are categorizing network
protocols by OSI layer (l2, l3, l4), and their various valid field values
(i.e. IP src, IP dst, etc.) and creating flow rules based on all possible
combinations of these. Then, a helper method parses the flow rule and
creates a scapy packet based on it, which we then transmit from the TG to
the SUT in order to validate the flow rule.
* Virtio testing for 26.03:
   * 1. Add a PvvP test, which will work just like the existing PvP test
(based on the virtio exception path example on the DPDK docs) except that
it will have two vhost backend instances.
      * So, the port order will be set to 1 (virtio), 3 (vhost loopback), 4
(vhost loopback), 2 (virtio)
   *  2. Otherwise, we need to ask Maxime what coverage he would like to see
* Cryptodev:
   * Now using dpdkruntimeenvironment to run the cryptodev application with
.run_dpdk_app()
   * Making param enums for the application, just like the testpmd approach
   * Able to form the EAL and app arguments now, and run the
dpdk-crypto-perf application via DTS
      * Having a few more issues with a couple remaining arguments
      * Then, Andrew will set up usage of the textparser for processing the
output of the dpdk-crypto-perf application
   * DTS should automate the creation of the virtual functions on the
crypto device
      * Can read the max_vfs file for the correct number of vfs to make per
PF, and then write that number to sriov_numvfs

Bugzilla discussions
* Andrew and Patrick pruned the tickets

Any other business
* Roadmap discussion (WIP):
   * DTS API
      * Remove all existing framework imports and replace with imports from
the DTS API
      * https://bugs.dpdk.org/show_bug.cgi?id=1788
   * Cryptodev testing
      * Adding a new cryptodev package to the DTS API for handling
dpdk-crypto-perf app arguments
      * (testsuites) : Encrypt/decrypt workloads with the various supported
algorithms on DPDK NICs.
   * Supporting DTS testruns on 1 physical host:
      * Ensure the documentation for testing on a single host with a single
NIC is up to date
      * Framework updates
   * Virtio testing support:
      * Enable additional testing topologies and scenarios (i.e. adding a
PvvP test which is structured similar to the existing PvP test)
   * Flow Offload Testsuites:
      * Add a new testsuite which categorizes network protocols and their
respective valid field values by OSI layer, and creates all unique
combinations of these as flow rules. This should create “comprehensive”
coverage of flow rules where previously we just had the minimal set of flow
offload rules tested.
      * Asynchronous API testing
         * (question) is this the same functionality as the synchronous
API, or a subset?
   * Additional functional ethdev testsuites:
      * Ethertype Testsuite
      * QinQ testing: Extend this testsuite to validate that IDs are being
stored in the correct TCI / OUTER_TCI via testpmd verbose logs
   * Update testsuite names for clarity:
      * https://bugs.dpdk.org/show_bug.cgi?id=1826
* Next meeting is Dec 18, 2025

[-- Attachment #2: Type: text/html, Size: 4816 bytes --]

                 reply	other threads:[~2025-12-12 19:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='CAJvnSUDz1j7H4hgYFHtwTpR593N8=O48_NHi+isKvDK4jSc6ng@mail.gmail.com' \
    --to=probb@iol.unh.edu \
    --cc=ci@dpdk.org \
    --cc=dev@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).