February 5, 2026 Attendees 1. Patrick Robb 2. Aaron Conole 3. Paul Szczepanek 4. Matt Labrecque
Minutes General Announcements * AI Code review: * Community is looking for a place to host the scripting which drives the AI reviews. The Community Lab is one candidate. * Tech board had discussion yesterday about what is the best place to send the AI reviews? Test-report mailing list? Dev mailing list? A new mailing list dedicated to AI reviews? * Thomas sent the API key to Patrick, it is being stored securely at UNH * Policy Discussion: * What are the conditions which should result in the AI code review being triggered? Aaron Conole suggested that all CI checks (from the 4 CI labs) should be passing before the AI code review is triggered * David Marchand added on that there should be a way for maintainers to manually override this / trigger a test * Aaron sent an initial patch with the scripting and prompts that drives the AI code reviews, and this will need to be reviewed and merged * Where will the prompts be stored? Should the community have access to the prompts so they can locally run the AI code reviews? Tech board says yes. So, they will need to be stored in a place which is accessible. * Concern: If someone submits a patch that modifies the prompts and that patch gets picked up by AI, that malicious submitter can send arbitrary (possibly malicious) prompts to the AI code review system. * Aaron idea: If we are about to submit a review request, if the series modified the prompt files at all, don’t submit. However, if it was modified, and a review comment sender is contained within the DPDK MAINTAINERS file, we assume the modifications are not malicious and the AI code review is submitted. * Once the initial Jenkins scripting is setup on the UNH side, and the scripting and AI review processes are submitted/under review for the DPDK repo, Aaron will most likely visit UNH to flesh out the process with the DPDK Lab team * DPDK Stockholm: * Patrick sent a draft RFC proposal to DTS folks about a talk which would demonstrate integrating DTS into the DPDK dev process, using the example of a flow offload update and the flow offload testsuite. * Aaron is planning to submit a talk about the new AI review scripting, etc. * Stephen Hemminger is working on a new python checkpatches script. This will be merged to dpdk/devtools. * Since the existing checkpatches pulls from linux kernel checkpatches, it is doing some checks which we would prefer not to and send noise to the DPDK submitter. So, we have outgrown this. So, we can continue to try to modify the checkpatches output, or just start from scratch and write our completely separate checkpatches script which only does what we want. * Also, python is nicer to work with vs perl, which means that the barrier of entry for contributions and maintenance will be less * The performance of the perl script is worse due to our “hacks” we add onto the checkpatches script * There was some discussion about trying to convince the kernel to integrate our new checkpatches approach, but Aaron raises that this will most likely not work because there are many, many other projects consuming the existing kernel perl checkpatches * Example: OvS is maintaining their own checkpatches and this has worked well in this community. CI Status AWS Lab * None UNH-IOL Community Lab * Tech Board: Fast Free does not mean no multi-seg * UNH guys will keep an eye on this for the performance testing, if the single core forwarding test needs to be updated so that it still works “normally” i.e. enable fast free via a testpmd runtime command in the test if it moves to disabled by default, we can do so. * Meson: When UNH runs testing jobs, for linux systems we run the .ci/linux-setup.sh script which sets the system to the “correct” version of meson at runtime. * This means that when the meson version is bumped, no coordination with the UNH lab is required. * Windows: UNH guys need to add simple conditions into our windows build pipelines that sets the meson version according to the DPDK version * We are migration off of our existing Red Hat FreeIPA server, which will require a little downtime in the near future. Patrick will schedule this. * For users who want to use the Intel Lab * None Github Actions Robot * Aaron started an implementation which would allow his CI to build an lcov/gcov code coverage report on a per patch basis * Needed to pass some options to force usage of atomics instead of standard increment decrement * fprofile-update=atomic * Will be incliuded as an artifact on the CI job for a patchseries * Eventually, Aaron would like to add post processing that will actually check whether new code is covered by a test vs not covered by a test, etc. Loongson Lab * None DTS Improvements & Test Development * Cryptodev testsuite (performance and functional): * Akhil emailed back with some further guidance for Andrew * “For Symmetric algos, 10 million is good and would be completed fast. But for Asymmetric, 100K (or 10K for some cases.)would be good enough.” * “In some of the drivers, cipher-only and cipher-then-auth have different path altogether. I would say, treat the cases as separate cases with all supported list of algorithms. If it takes too much of time, we can stick with the commonly used algos which are supported By all PMDs. You can check https://doc.dpdk.org/guides/cryptodevs/overview.html For the list of supported algos. * Andrew is adding an additional “@crypto_perf” tests decorator, beyond the existing @func and @perf decorators, since the crypto perf tests do not require a performance traffic generator to be setup. * Flow Offload: * Patrick reviewed - Dean working on the next version currently. * DTS docstrings format script: * Merged * Missing Qinq rst file * merged Any other business * Next meeting is Feb 19, 2026
