DTS WG Meeting Minutes - January 31, 2024

[Patrick Robb <probb@iol.unh.edu>]

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

January 31, 2024

#####################################################################
Attendees
* Patrick Robb
* Juraj Linkeš
* Paul Szczepanek
* Jeremy Spewock
* Luca Vizzarro
* Thomas Monjalon

#####################################################################
Agenda
* Additions to the agenda
* Patch discussions
* DTS Developer documentation
* 24.03 roadmap

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

=====================================================================
General Announcements
* Added developers for DTS: Nick from UNH is starting on DTS now, and 1-2
more people from UNH will be starting on this project in the near future.

=====================================================================
Patch discussions
* Dockerfile patch is updated to fix poetry installation and add
documentation for using SSH keys.
   * We are not going to COPY in the keys to the image from the Dockerfile.
New approach is volume mounting ~/.ssh to the container at Docker run, and
readme is provided explaining this process
   * Patrick Robb will run this, add a tag on the patch, and request a
merge from Thomas
* Scatter is submitted and has been reviewed by Juraj, looking for more
reviews from community members to get that patch moving.
   * Can have 1 test for no offload, and 1 test for including offload
      1. If scatter is not available, we should expect a failure in the
second case.
      2. Feature is underdocumented currently
      3. We can add a patch adding comments documenting the feature. All
lines in ethdev.h should be commented, so it is a “bug” that additions from
early dpdk days are not well documented. (RTE_ETH_RX_OFFLOAD_SCATTER)
      4. doc/guides/nics/features.rst - this file documents the feature
matrix, what the feature does and how we determine if the feature is
available.
* Docstring patch: What is the latest status of the needed meson changes?
Has Bruce provided any feedback?
   * Bruce said he was OK with the patch, but Juraj is not
   * The docs don't look as good as they probably could.
   * The current process generates the docs in two steps: one generates the
.rst inputs for Sphinx (using the sphinx-apidoc tool), the second step then
generates the actual html docs from the .rst file.
   * Juraj is looking into removing the sphinx-apidoc step from meson and
having a semi-manual way to produce the .rst files: running the
sphinx-apidoc locally the first time (or when there's a big change to file
structure) and adding new files manually (which is very easy copy-paste
with just a few changes).
   * The second approach gives us much better control over how the docs
look and how we structure the pages.
   * Do we want to generate docs from test suites? This is likely an item
for the future.
   * Action item: Try to generate the docs, give feedback on how it looks,
give feedback on maintenance.
* Blocked test case results recording: In progress, needs rebase on top of
docstrings and finishing touches.
* DTS Documentation from Luca.
   * Has been merged by Thomas now.
   * We might want to move around some documentation so it is more
logically partitioned for readers.
   * Juraj is ok with the patch, but Thomas wants bigger changes. We need
to agree on what we do in this patch and what in other patches.
   * Possibly related are these bugzilla items:
      1. DTS: Split testbed and test configuration
      2. DTS: Rename the execution section/stage
      3. DTS Config improvements
   * On one more item that came up during the review:
      1. DTS: add support for externally compiled DPDK

=====================================================================
The original DTS patches
* Thomas pinged Intel people to check whether there can be a final round of
DTS patches merged, or some minimal support for that repo going forward.
There are some tens or hundreds of patches which were submitted after
Lijuan Tu (old maintainer) left Intel, which are just languishing in the
dts mailing list.
   * Jeremy has a patch extending timeout for DTS which he can submit, but
only if there will be more merging coming up
   * Patrick has some patch(es) adding cx6 and cx7 NICs to old DTS.
Technically our testbeds running now are forked. When setup is 100% done
for both NICs, intending to circle back and add these NICs to upstream DTS
if merging is a possibility.
New/Open feature requests
* How do we want to handle feature requests for the framework going
forward? We have a lot of needed features dumped into bugzilla now (thank
you Juraj), but how do we prioritize, filter through what is most important
for each release?
   * Patrick suggests: incorporate bugzilla tickets into release roadmaps,
assign them to individuals, and set action items at each DTS meeting for
bugzilla tickets.
https://bugs.dpdk.org/buglist.cgi?bug_status=__open__&component=dts&product=DPDK
   * We can also run through all the tickets during meetings, and set the
“importance” value for any new tickets

=====================================================================
24.03 Roadmap
* Can we extend this?
   * Should we add another ethdev suite to work on?
      1. Mtu update is running in the lab currently and seems like it would
be a good candidate. Only thing to consider with this suite is that the old
DTS version is broken on all non-intel NICs due to a mismatched assumption
about VLAN headers, so that could lead to some getting stuck in the weeds.
This suite could also be done in two main ways that I can think of, either
we verify that the packet was forwarded or not by checking the number of
packets sent and received on the port, or we could instead just see if we
get anything back on the tg side. Checking if we received a packet on the
tg side would be more seamless with what we have but either way could lead
to false positives.
      2. Jumboframes would also be a reasonable option, the only thing to
consider with this suite is one of the cases is a “didn’t receive anything”
case currently which could easily lead to both false positives if something
went wrong, or false negatives with the lack of bullet-proof packet
filtering.
      3. Mac-filter would force us to introduce something new to the
framework which is verification using the number of packets received. Could
be difficult if there is any other noise on the interface.

=====================================================================
Action Items
* Jeremy Spewock will be working on
https://bugs.dpdk.org/show_bug.cgi?id=1359 bugzilla ticket
* Juraj Linkeš will be taking this ticket:
https://bugs.dpdk.org/show_bug.cgi?id=1365

=====================================================================
Any other business
* What should be the deadline for DTS changes in the release cycle? DTS
changes will never break DPDK functionality, but we want some reasonable
buffer between changing a test and a release.
   * Proposal: RC2 deadline for modifying an existing test or modifying the
DTS framework, RC3 for adding a new test
* Please read Gregory’s email about writing testsuites in his “unit test”
app, for the flow API, creating flow rules and how he validates for sending
packets with a certain VLAN id, etc.
* Packet filtering is something that has been tossed around and discussed
here and there but one idea that was mentioned was just adding a few bytes
to the end of every packet as a sort of “DTS header” that we could check
for the presence of to ensure that the packets are relevant.
   * Could this cause issues with suites that require certain MTU sizes? If
so it doesn’t seem difficult to account for when setting packet lengths.
   * Are there any test suites where a packet would get sent to the SUT and
in getting forwarded back these extra bytes get stripped? Is there a test
case where you send one packet to the SUT and the SUT forwards multiple
packets back?

=====================================================================
Notes on gathering device capabilities:

* In the short term we should move to gathering device and queue
capabilities as a preliminary step for a testsuite, and execution the
testsuite (or specific testcases) based on information gathered. Then we
also use testpmd for configuring.

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