From: Patrick Robb <probb@iol.unh.edu>
To: dev <dev@dpdk.org>
Cc: ci@dpdk.org
Subject: DTS WG Meeting Minutes - January 30, 2025
Date: Thu, 13 Mar 2025 19:08:47 -0400 [thread overview]
Message-ID: <CAJvnSUAxrYVaiSQnAdQ_h+7ZfAOcWBWkZC38=K8AKAWx4bpHqg@mail.gmail.com> (raw)
[-- 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 --]
reply other threads:[~2025-03-13 23:12 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='CAJvnSUAxrYVaiSQnAdQ_h+7ZfAOcWBWkZC38=K8AKAWx4bpHqg@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).