DTS WG Meeting Minutes - January 30, 2025

DTS WG Meeting Minutes - January 30, 2025

[Patrick Robb]

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

#####################################################################
January 30, 2025
Attendees
* Patrick Robb
* Luca Vizzarro
* Thomas Wilks

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

=====================================================================
General Discussion
* Async sniffer failures
   * One issue was lack of ip link up in testsuite setup. This is resolved
now with latest next-dts commit.
   * Unclear if there are any other issues.
* We’re ~20 patches away from a healthy backlog - reviews are needed
* Re-asses DTS 25.03 Roadmap
   *
https://docs.google.com/document/d/1doTZOOpkv4D5P2w6K7fEJpa_CjzrlMl3mCeDBWtxnko/edit?tab=t.0
* Discussion on raw payload comparison
* DTS usage in cloud environments
   * Checked with Azure - they cannot provide an L2 network for testing
   * Will discuss an implementation at a future meeting

=====================================================================
Patch discussions
* Rework topology config
* runner.py rewrite
   * Luca has a runner.py rewrite which attempts to improve separation of
concerns in the framework. Creates new class - testrun - configures runtime
and testsuites. Testrun class spins up testsuites and testcases
independently. It is a state machine instead of a deep call stack.
      * Stores current state and context of dts, updates as we go.
      * By creating a context, we improve the developer experience, as we
also enforce a division between the framework internals and the test (the
testsuite writing plane)
      * We need to ensure that the API is consistent. Because the framework
internals are constantly changing, we do not want developers to have access
to these (like the nodes).
         * Only topology for a particular testrun is available for a
testsuite
         * Testsuites will not “touch” ports not a part of the list of
ports they need
         * Tg shell and testpmd shell will get all the information they
need via the context
         * No need to differentiate between tg nodes and sut nodes (a node
just has hardware information)
         * Runtime parameters for the tg or dpdk app are contained within
the testrun (instead of the nodes themselves)
         * Will reduce duplication and simplify the testsuite code.

=====================================================================
Bugzilla discussions
*

=====================================================================
Any other business
* High level parallel func testing discussion:
   * * Next meeting is Feb 13, 2025

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