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.