#####################################################################
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