October 12, 2023
#####################################################################
Attendees
1. Patrick Robb
2. David Marchand
3. Lincoln Lavoie
4. Aaron Conole
5. Paul Szczepanek
6. Ali Alnubani
7. Thomas Monjalon
8. Adam Hassick
9. Honnappa Nagarahalli
10. Juraj Linkeš
#####################################################################
Agenda
1. General Announcements
2. CI Status
3. DTS Improvements & Test Development
4. Any other business
#####################################################################
Minutes
=====================================================================
General Announcements
* There will be a joint governing board and tech board meeting next Tuesday, related to 2024 work and contracts
* There will be a section devoted to discussion about the proposal of adding an additional dedicated DTS developer at the Community Lab
* This would entail improving the actual testing framework and integrating it into the DPDK repo, and also porting over testsuites/writing over testsuites
* Aaron did merge some patches from UNH to the dpdk-ci repo:
* Container template engine from Adam Hassick
* Get_reruns.py regex script for collecting retest request labels from comments on patchwork API has been merged
* Pw_maintainers_cli.py: There has been a v2 of this patch submitted, which resolves the initial concerns from Aaron and David
* The patch from Bruce which allows you to set an env variable and skip a particular unit test from a suite is merged
* Short term boon: unh can re-enable it’s arm64 unit testing
* This arm64 EAL unit test issue has probably been fixed by David’s patch (merged yesterday to mainline) which cleans up between unit tests. This has not likely hit subtrees yet, but subtree maintainers will likely rebase from main very soon because of rc1
=====================================================================
CI Status
---------------------------------------------------------------------
UNH-IOL Community Lab
* Nvidia testing:
* Hardware Refresh
* cx6-Lx NIC is now in production for performance testing, reporting to patchwork: https://mails.dpdk.org/archives/test-report/2023-October/477804.html
* UNH is going to order an additional cx6-lx nic so that we can have 2 nics on the DUT and utilize only 1 port per nic instead of 2 (current approach)
* CX7: installed in NVIDIA DUT server, and Intel tester TG server.
* Need to aggregate info regarding any changes required for the system and send to Intel contacts
* Do NOT install OFED - just need to use most recent distribution
* Trex can run without ofed, but we will need to include a flag indicating we should run without ofed
* This is ideal in Patrick’s opinion, since the TG nic is on an Intel donated server, and I don’t want to disrupt their testing
* Required TREX arg: --no-ofed-check
* Are there functional testsuites which should be run on these cards?
* There are internal conversations about what is most important to be tested, we will circle back on this later
* Intel 8970 QAT Accelerator card: Dharmik from ARM is providing feedback on our setup so we can align with his
* TS-Factory:
* Does run on arm, so x86 and arm parity in testing should be achievable
* Our setup “ts-rig” seems sound, and our results in alignment with oktetlabs
* Still need to setup the Jenkins scripts and Dashboard page (run on periodic basis)
* We will deploy 4 environments (x86: xl710, cx5) and (ARM: xl710, cx5)
* Apply patchset script:
* We have a draft script which should be generic and can be upstreamed to dpdk-ci
* Includes a small config file to track basic git-pw info needed for dpdk (pw api url, repo syntax (main vs /next/ trees), etc.
* Tries to apply on the “predicted tree” from the script first, then tries to apply on main
* Depends on: not implemented yet, but we will try to implement via git-pw itself so we can contribute to that project. Or, if we run into any trouble we will fall back on implementing it directly in our apply script.
* If there is more than one depends on patch in the commit message, we will attempt to apply “top to bottom”
* Apply failures will be reported if we fail here
* Marvell Octeon board: Still working with their support to get documentation, but they have approved our account request
* We have a contact which runs DTS at their company now, who will help us on setup
* John McNamara is the new Intel contact for UNH stuff
* There is a new validation manager being onboarded who will be the contact long term
---------------------------------------------------------------------
Intel Lab
* Small hiccup recently over a testbed being powered off for a couple days
---------------------------------------------------------------------
Loongarch Lab
* Still working fine but no news
---------------------------------------------------------------------
Github Actions
* Still working on server migration plan, waiting on security audit internally. There is a testing environment up for the migration. There have been some delays on the systems getting moved, which has extended the timeline.
* Final testing needed on the robot email based retesting framework support
=====================================================================
DTS Improvements & Test Development
* Dperf: We are asking him about L2 traffic
* Scatter: Jeremy is bugfixing for this, and running it across a few NICs to verify the implementation is correct
* He noticed that there wasn’t a step in the execution setup rebinding the SUT interfaces from the os_driver to the dpdk driver, so he is going to submit a separate patch along with the scatter patch adding in this step
* 23.11 patches are looking good, should be ready by the deadline
* What should we work on for 24.03?
* Paul: Before asking developers/maintainers to write testsuites we need to verify the framework is ready and tools in place to facilitate this (and it should be easy for developers)
* The testpmd handler needs to be extended to facilitate the writing of all testsuites which will be required in dpdk
* Need to make sure that we don’t need to explicitly update the python wrapper to support every new testpmd feature every time testpmd is updated. But we also need to facilitate easy of use for the wrapper, which might not mean directly passing to testpmd. It should be possible to support both (maybe override the level of abstraction only when needed). We can make this as dynamic as is needed to allow for complete use of testpmd features.
* Currently EAL parameters and testpmd parameters are passed separately from the wrapper.
* We need to verify logging/error reporting is up to snuff
* Juraj wants to spend time researching what might we be missing in terms of what needs to be added before we are ready to go to the broader community and have them write testsuites. He will work on this once all 23.11 work is done.
* Work on 1 testsuites per module in dpdk
* Jeremy and Patrick will discuss what are some testsuites which could be ported over for the next release
* Patrick will aggregate the dpdk testsuites run in the lab, and what we would like to run but does not work
* Testbed config: we have a few values which we are not currently used
* Build target has 5 values, only 2 are being used
* Not using arch, os, and cpu. Having these values included comes from old DTS, but it may no longer be needed. They could be useful for cross compilation in the future, but we can remove now and re-add later if needed. We still probably won’t even need these values for cross compilation, since all we will need is to be able to reference the cross file.
* Use_first_core: eliminate this option. New process should be like - if no lcore list is explicitly stated, dynamically select the cores, but always skip the first core. If lcore list is explicitly states, use the list!
* Interactive session: currently only supporting ssh, do we want to support anything else (telnet?)
* This might be required for IXIA TG
* We can do this later if the community needs
* How we use the word “execution” in DTS is confusing
* When we say DTS execution, people will typically think of the entire dts run, but there are actually multiple dts executions within one DTS run, and this terminology is not intuitive for people coming in
=====================================================================
Any other business
* Testing DPDK use in cloud platforms (aws, google cloud, etc)
* Governing board has asked about the Community Lab setting this up, running it in 2024
* What use cases should be covered? Does anyone have any insight from cloud usage at your companies?
* Honnappa: single core performance test would be good to run for cloud platforms
* Honnappa: Running unit test cases in the cloud. In his experience he ran into issues running in the cloud due to race conditions in the unit tests.
* Scalability testing. We focus on single core performance, but we need to move beyond that. Can we run l2/l3fwd on many cores
* Virtio testcases (obviously important in cloud environments)
* Next meeting is October 26, 2023