DPDK patches and discussions
 help / color / mirror / Atom feed
* DTS WG Meeting Minutes - February 27, 2025
@ 2025-03-13 23:26 Patrick Robb
  0 siblings, 0 replies; only message in thread
From: Patrick Robb @ 2025-03-13 23:26 UTC (permalink / raw)
  To: dev; +Cc: ci

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

#####################################################################
February 27, 2025
Attendees
* Patrick Robb
* Paul Szczepanek
* Luca Vizzarro
* Ian Stokes

#####################################################################
Minutes

=====================================================================
General Discussion
* RC2 is Feb 28, 2025

=====================================================================
Patch discussions
* VF port support: Patrick is trying to refactor this, with these
assumptions
   * 1. Port class gets a new attribute, virtual_functions, which is a list
of VFs (type Port). From looking at a couple VF testsuites we want to
provide, it seems that having the PF -> VF(s) relationship handled in this
way is sufficient.
      * VFs will automatically have the mac attribute assigned
      * Will not have the logical name attribute assigned (does not exist
in linux for VFs)
   * 2. Still unsure of how to handle VF #
      * 2.1 One option is to just check
/sys/class/net/{device_logical_name}/max_vfs and set the maximum number of
VFs possible per physical port at physical port initialization
      *  1.2 Or, set VF as a capability on testsuites or testcases and
reset at runtime.
   * 3. Users will specify whether the testrun is a physical function
testrun or virtual function testrun in the testrun config
   * 4. It may make sense to run PFs and VFs across the same testsuites
instead of splitting a test plan into 2 testsuites (like vf_l2fwd and
pf_l2fwd)
   * 5. Possible footguns: promiscuous mode can behave differently for VFs
vs PFs. VFs may require additional configuration in order to trust traffic
which does not match the VF MAC.
* TREX perf TG support:
   * 1. Users will be expected to create a trex config file, and provide
the path in their config
   * 2. In legacy DTS perf tests started first by launching scapy, and
using wrpcap() to write some pcap files in the DTS dir, which would get
picked up by TREX later. Nick is investigating but soon we will have to
determine whether these pcaps are needed, and if so whether we prefer to
write them to the system at runtime or simply provide them as “helper pcap”
files in the repo.
   * 3. Nick will evaluate trex dpdk_nic_bind.py vs dpdk-devbind.py but
most likely they are the same
* Dean is refactoring some old testsuites:
   * Port stats check: done (Patrick needs to review)
   * rx/tx_offload: nearly done
* Ethertype:
   * VLAN/TPID Filtering testcases for the ethertype testsuite cannot be
run on some devices in the UNH lab due to
https://bugs.dpdk.org/show_bug.cgi?id=1464
      * UNH guys will work with the Intel and Broadcom PMD maintainers to
resolve these filtering issues, and then circle back to this testsuite for
25.07
* RSS tests up and ready for review
* Paul proposes renaming context to "DTS" and make it a stable API
   * Rename Context to DTS, pass in as dts argument to test case functions
this contains the tg, sut, logger and other context needed by the testcase
   * Users import DTS (module) and not framework
   * Anything required by test writer is proxied by DTS - this becomes a
stable API we promise to maintain, not affected by framework changes
   * Calls should be intuitive and match hierarchy
      * E.g. self.send_packet() -> dts.tg.send_packet()
      * With TestPmdShell() as testpmdshell: testpmdshell.start() ->
dts.sut.testpmd.start()
      * dts.tg.log(), dts.sut.log()
      * Dts.verify etc. it’s clear you’re making a dts call not call to
your own testsuite class
         * Can use python assert instead of verify
* Per-test-suite configuration
   * Keep configurations of individual test suites in distinct files?
      * Considering a new test_run field to specify a glob-like path
      * E.g. ./tests_config/{test_suite}.yaml
      * Could potentially make it easier if we keep different configs in
the same folder, but different test runs: e.g. func.{test_suite}.yaml,
perf.{test_suite}.yaml
   * Do we provide overrides for individual test suites?

=====================================================================
Bugzilla discussions
* https://bugs.dpdk.org/show_bug.cgi?id=1464
   * Dean sees the error message for VLAN assignment in i40e driver from
the verbose logs, and we will forward this along to Intel guys
   * Need to produce verbose logs for Broadcom too
   * Noting that this issue does not exist on Mellanox

=====================================================================
Any other business
* Roadmap status:
https://docs.google.com/document/d/1doTZOOpkv4D5P2w6K7fEJpa_CjzrlMl3mCeDBWtxnko/edit?tab=t.0
* Next meeting is Mar 13, 2025

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2025-03-13 23:29 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-13 23:26 DTS WG Meeting Minutes - February 27, 2025 Patrick Robb

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