January 18, 2024 ##################################################################### Attendees 1. Lincoln Lavoie 2. Thomas Monjalon 3. Aaron Conole 4. Jeremy Spewock 5. Paul Szczepanek 6. Ali Alnubani 7. Juraj Linkeš ##################################################################### Minutes ===================================================================== General Announcements * First 2024 DTS WG meeting was held yesterday, and the minutes are here: https://docs.google.com/document/d/1pG_NGuwYgPuovwIfhvcs9u8PNYIJuInsFr0GeTUIU4k/edit?usp=sharing * Patrick Robb will publish the meeting minutes ===================================================================== CI Status --------------------------------------------------------------------- UNH-IOL Community Lab * Octeon CN106XX: Patrick worked with Hiral this week about the process for SDK rebuild. This will have to happen regularly, but we now have a VM setup which will serve as the place to rebuild SDK and act as TFTP server for the Octeon board. * After that we need to iron out switching rootfs to ubuntu, setting up DTS on the tester, validating this works fine in a CI context (Phanendra from Marvell has approved of the concept). * The Intel server arrived in the mail yesterday. We will mount the system this week and begin setup. As a reminder this now unblocks: * E810 testing for Intel * Traffic gen for the CX7 testing (this server will act as TG) * Traffic gen for the Octeon CN106xx board * The new create dpdk artifact for ci testing script is in production at UNH, and Adam is submitting the V3 patchseries for this to dpdk-ci today * There is an update from the patchwork maintainer about supporting Depends-on via patchwork. I encourage everyone to read his full thoughts on the issue below, but shorthand conclusions are: * He prefers to only support Depends-on on a series basis, not a series or patch basis. * Patrick will update the CI testing thread on this topic, but this may require the DPDK community agreeing to a new approach. From looking through the dev mailing list, it seems that series dependency is the typical use, but there are also some examples of developers using patch dependency. * Keep the same syntax which allows for depends-on: patch, but in reality translate this to depends on that patch’s series * He will need some help for the effort. We can ping the DPDK community to look for volunteers. Or, it can possibly become a community ask for development at the DPDK Community Lab. Looking at it at a high level I don’t think the scope will be too bad. * Full thread: https://github.com/getpatchwork/git-pw/issues/71 * Arm-Ampere still needs a kernel rebuild for the QAT card * Standing up ts-factory testing framework * Adam did the first cx-5 run on an ARM system, and will do an Intel XL710 run on an ARM system today. Both will be published on Oktet Lab’s Bublik for review. * Unlike our ARM testbeds, our x86 servers are single server TG/DUT testbeds, which breaks an assumption in ts-factory. My view on how to proceed is bring testing online with what works now (arm), then review the value with the community, and choose a strategy for x86 based on what we learn from running this at the lab. * Andrew from Oktet labs has added some missing components to GitHub for the data visualization tool (Bublik), and has finished categorizing the tests for the XL710 and the expected results for that NIC * Old DTS patches: * We noticed that as DPDK has grown, the compile time also increases and the old compile timeout for the DUT is no longer valid on some slower systems. Jeremy will submit a patch extending the timeout. * Once the cx7 is online, patrick will submit the patch adding the cx6 and cx7 to the NIC registry in DTS * Lincoln saw the email thread about DPDK failing to build on FreeBSD 14. We are only testing FreeBSD 13 in the lab right now, so we will add coverage for 14. --------------------------------------------------------------------- Intel Lab * John says there is still no new person who can act as a contact. There have been further staffing changes at Intel, so it may be hard to get a contact soon, but Patrick will keep asking. --------------------------------------------------------------------- Github Actions * Cirrus CI: Adding support for this to the 0 day robot. Aaron submitted a patch for polling for Cirrus ci status in ovs. * They are getting a server to migrate the VM over to, so there should be minimal downtime associated with the hardware moving from Westford to another state. --------------------------------------------------------------------- Loongarch Lab * None ===================================================================== DTS Improvements & Test Development * scapy/templated yaml for tests: * One motivation is for making writing simple tests in minimal time (like 3 minutes). Should we aim for a target of writing a testsuite in minutes, not hours? * Testing is broken down into phases, and you simply write in the raw scapy commands or values to pass to testpmd * At the end, compare output string to an expected output string written in the YAML * Is it possible to get the best of both worlds? We can try to remain with python only, but use python annotations and assign python to TG, DUT commands etc. * Gregory also splits the configuration of platform and test configuration. * We should draw up a “pseudo” version of this structured test setup via python, and review as a group * If we can draw this up we can compare against a currently written test (like Jeremy’s scatter test), and then we will have a practical example of the effort difference between the two approaches. * The API will evolve over time - for drawing up an example, we can make up whatever we want * By using a templating system (or some python “syntactic sugar”), we may remove some of the boilerplate overhead form writing a suite - possibly a major value for making writing testsuites easier. * Obviously this all needs to be documented. * Paul: It may be a good approach to have a few more people write at least one testsuite according to the current approach. Then, we use these new tests to guide the creation of the “new” approach. Hopefully we learn what works, what needs to be improved and refactored out into the framework - pre-proving the validity of the new approach. * All DTS people will try to workshop next week to investigate what a new approach would look like in concrete terms. * DTS group will go through all the new Bugzilla tickets at the next DTS meeting. * Jeremy has volunteered to at least one during this release: * https://bugs.dpdk.org/show_bug.cgi?id=1359 ===================================================================== Any other business * Next Meeting: February 1, 2024