From mb at smartsharesystems.com Sat Nov 1 08:47:11 2025 From: mb at smartsharesystems.com (=?UTF-8?B?TW9ydGVuIEJyw7hydXA=?=) Date: Sat, 1 Nov 2025 08:47:11 +0100 Subject: Disable SPDK testing again? In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35F65520@smartserver.smartshare.dk> Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65526@smartserver.smartshare.dk> > From: Patrick Robb [mailto:probb at iol.unh.edu] > Sent: Friday, 31 October 2025 16.13 > > On Fri, Oct 31, 2025 at 6:02?AM Morten Br?rup wrote: > >> If we disable SPDK testing due to this SPDK bug, how will we notice when they fix it, so we can enable SPDK testing again? > >> One option?is I can disable SPDK testing for the "per-patch" testing, but leave it enabled for the periodic (once per 48 hours) runs on DPDK main. That way patch submitters aren't left wondering if their patch has broken SPDK, but we will be able to check in later on the DPDK main periodic builds to see if the SPDK side is fixed, at which point we can re-enable SPDK for per-patch testing. Yes, please do. From probb at iol.unh.edu Mon Nov 3 02:06:05 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Sun, 2 Nov 2025 20:06:05 -0500 Subject: Disable SPDK testing again? In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65526@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35F65520@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35F65526@smartserver.smartshare.dk> Message-ID: Okay I'll push this change Monday morning. On Sat, Nov 1, 2025 at 3:47?AM Morten Br?rup wrote: > > From: Patrick Robb [mailto:probb at iol.unh.edu] > > Sent: Friday, 31 October 2025 16.13 > > > > On Fri, Oct 31, 2025 at 6:02?AM Morten Br?rup > wrote: > > > >> If we disable SPDK testing due to this SPDK bug, how will we notice > when they fix it, so we can enable SPDK testing again? > > > >> One option is I can disable SPDK testing for the "per-patch" testing, > but leave it enabled for the periodic (once per 48 hours) runs on DPDK > main. That way patch submitters aren't left wondering if their patch has > broken SPDK, but we will be able to check in later on the DPDK main > periodic builds to see if the SPDK side is fixed, at which point we can > re-enable SPDK for per-patch testing. > > Yes, please do. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Mon Nov 3 22:17:26 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 3 Nov 2025 16:17:26 -0500 Subject: Disable SPDK testing again? In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35F65520@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35F65526@smartserver.smartshare.dk> Message-ID: All set. On Sun, Nov 2, 2025 at 8:06?PM Patrick Robb wrote: > Okay I'll push this change Monday morning. > > On Sat, Nov 1, 2025 at 3:47?AM Morten Br?rup > wrote: > >> > From: Patrick Robb [mailto:probb at iol.unh.edu] >> > Sent: Friday, 31 October 2025 16.13 >> > >> > On Fri, Oct 31, 2025 at 6:02?AM Morten Br?rup >> wrote: >> > >> >> If we disable SPDK testing due to this SPDK bug, how will we notice >> when they fix it, so we can enable SPDK testing again? >> > >> >> One option is I can disable SPDK testing for the "per-patch" testing, >> but leave it enabled for the periodic (once per 48 hours) runs on DPDK >> main. That way patch submitters aren't left wondering if their patch has >> broken SPDK, but we will be able to check in later on the DPDK main >> periodic builds to see if the SPDK side is fixed, at which point we can >> re-enable SPDK for per-patch testing. >> >> Yes, please do. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Nov 4 04:34:14 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 3 Nov 2025 22:34:14 -0500 Subject: DTS WG Meeting Minutes - October 9, 2025 Message-ID: #################################################################### October 9, 2025 Attendees * Patrick Robb * Luca Vizzarro * Andrew Bailey #################################################################### Minutes ===================================================================== General Discussion * None ===================================================================== Patch discussions * RSS Testsuite: * Patrick to review * Mbuf fast release testcase / tx_offload: * Looks good overall * Most likely the testcase will need to be updated to reflect the latest tech board decision on mbuf fast free (it is now enabled by default instead of disabled by default) * Virtio: * V2 looks good to Patrick. When it is final - send to Maxime (virtio maintainer) for his review * Single_core_fwd_perf: * Patrick is going to send a V5 which adds a performance_metrics.json * Traffic Generators are setup and torn down as needed. As a part of this, Patrick flattened the shell pool system so that there are no longer testsuite and testcase level shell pools, but this removes some safety (it stops protecting us from rogue shells which didn?t get closed * Can we add a flag (like persist) that allows a shell to be added without being added to the shell pool? Need to ensure this is cleaned up in testrunteardown * Move testsuite methods to API modules * Patrick to do a review ===================================================================== Bugzilla discussions * None ===================================================================== Any other business * Roadmap status review: * https://docs.google.com/document/d/1doTZOOpkv4D5P2w6K7fEJpa_CjzrlMl3mCeDBWtxnko/edit?tab=t.0 * Next meeting is Oct 23, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Nov 4 04:34:23 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 3 Nov 2025 22:34:23 -0500 Subject: Community CI Meeting Minutes - October 16, 2025 Message-ID: ##################################################################### October 16, 2025 Attendees 4. Patrick Robb 5. Luca Vizzarro 6. Indira K 7. Andrew Bailey 8. Aaron Conole ##################################################################### Minutes ===================================================================== General Announcements * Mbuf_fast_free * Tech board has voted that this feature will be reverted back to it?s 25.07 default behavior, meaning it will be enabled by default at start, and it is not mutually exclusive with MULTI_SEGS flag * Proposed new tag for reporting AI bot reviews: * Instead of linking to an email which contains the github link, link directly from the patchwork report to Github. ===================================================================== CI Status --------------------------------------------------------------------- AWS Lab * Looks like their test results are a little behind - Patrick to check this after the meeting. --------------------------------------------------------------------- UNH-IOL Community Lab * Community Lab retrospective for 2025: https://docs.google.com/document/d/1b-Jhbne_ucd1YIAK8BjKWWbTyvFTwUrWjAJaoJDmakg/edit?tab=t.0#heading=h.k82m3uansnww * The new Windows server 2025 machine is working. Most importantly, it is able to build DPDK with devx libraries included from meson, something we could not do from windows server 2022. * Dean is building a spreadsheet with all of the DTS testcase failures for various network cards at the Lab. * Some of the docs for meeting dependencies for the windows compiler toolchains are wrong (linking you to the wrong version) so Andrew will email Andre Muezerie asking if the docs can be updated. * Patrick needs to stand up pw-ci and also needs to review the preliminary series Aaron had sent for porting over the bash scripts from Python. --------------------------------------------------------------------- Intel Lab * Technically, this team can re-enable their tx_offload testcases which were originally disabled due to the upcoming mbuf_fast_free change. But, it is probably not worth doing so given that tech board is going to re-assess fast free again in 26.03. Github Actions Robot * None --------------------------------------------------------------------- Loongson Lab * Min Zhou has sent a MAINTAINERS patch removing himself and adding another Loongson employee. I am asking whether he is also transferring Loongarch CI testing duties to this new person. ===================================================================== DTS Improvements & Test Development * Test and Packet API: * Just 1 docstring update needed * Reviewed by and approved by Patrick * Single_core_forward_perf: * For the next version, have added the new TestSuite function for adding an arbitrary dict of performance metrics and writing it to testsuite specific output files. * Of course this will come from API at the end of the day. * Also need to add the shell pool exception for traffic generators so they can be instantiated within testcases and persist beyond the testcases stages * QinQ Test: * There are quite a few comments on the patches, Dean needs to send a v2 * Patrick to merge this * Single link topology * Docs failure is coming from circular imports between framework capabilities.py and api capability.py - Dean to look at this closer after his work on the QinQ series is complete. * add test case docstring checks to format script * There are a number of comments, Dean to send a v3 * Testsuite docstring updates: * Unclear if this series from Dean is overlapping with work Thomas Wilks had also done updating testcase docstrings during this release. Patrick to check and discuss with Dean. * RSS Testsuite: * Pending final review from Patrick * Virtio vhost series: * Luca and Patrick both need to review * Testpmd API: https://patchwork.dpdk.org/project/dpdk/patch/20250910152103.976383-2-paul.szczepanek at arm.com/ * Before, when a test was skipped due to a missing capability, the capability name was printed in the logs ?reason? field. Now, it just prints the number ID for the capability since capabilities were updated to an IntEnum ===================================================================== Any other business * Next Meeting is Oct 29, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Nov 4 04:34:46 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 3 Nov 2025 22:34:46 -0500 Subject: DTS WG Meeting Minutes - October 23, 2025 Message-ID: #################################################################### October 23, 2025 Attendees * Patrick Robb * Luca Vizzarro * Andrew Bailey * Paul Szczepanek * Indira #################################################################### Minutes ===================================================================== General Discussion * RC1 is about to release ===================================================================== Patch discussions * Mbuf fast release testcase / tx_offload: * Rebased this morning * Patrick to give it a testrun and merge today * Cover letter is missing but we can still review and merge * Virtio: * Dean working on a couple comments from Luca and Patrick and will send a v3 * Single_core_fwd_perf: * Patrick sent the v5 * The changes are: * 1. Adds a new api/test function for writing a performance_metrics.json file within output/{current_testsuite} * 2. Adds a new option to create a new interactive shell without adding it to the current shell pool, which allows it to persist beyond the current stage in the testrun. * API test.py and packet.py: * Includes test and packet functions for testsuites * Merged by Luca * Everyone needs to rebase their testsuites now that this has been applied, and use the new verify etc. * RSS: * Patrick to do a review * dts: add steps and verify sections to docstrings * Most likely a duplicate, Patrick can mark as rejected after confirming ===================================================================== Bugzilla discussions * None ===================================================================== Any other business * Roadmap status review: * https://docs.google.com/document/d/1doTZOOpkv4D5P2w6K7fEJpa_CjzrlMl3mCeDBWtxnko/edit?tab=t.0 * Next meeting is Nov 6, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Nov 4 04:35:56 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 3 Nov 2025 22:35:56 -0500 Subject: Community CI Meeting Minutes - October 30, 2025 Message-ID: ##################################################################### October 30, 2025 Attendees 1. Patrick Robb 2. Andrew Bailey 3. Aaron ##################################################################### Minutes ===================================================================== General Announcements * Release Candidate 2 (RC2) will be released by the end of next week. * DPDK Tech board voted on UNH Community Lab priorities for 2026, and we discussed the goals at tech board yesterday: https://docs.google.com/spreadsheets/d/1VXfO2vhiUwlRoGldEtHaKuyIa-tZ05QvPsuMUZNlJck/edit?gid=0#gid=0 * DTS: * priority on pushing DTS out to broader use by the community * To this end, Patrick to submit a patch with an edit to the DPDK contribution guidelines, adding a new requirement that ethdev patches come in with DTS testcase additions/updates for the patch. We did not define a timeline for merging this (I gathered it would not be during 25.11) but it makes sense to get the patch ready. * Priority on reducing the barrier of entry for writing testsuites / reducing lines of code required. We have already done some work to facilitate this but it makes sense to take another pass at it and see what further improvements are possible. * Patrick should forward to Andrew the old thread with Gregory, Thomas, Honnappa etc. about dpdk unit test, parsing YAML to tests (an idea we did not adopt), and the broad goal of reducing lines of code required to write a test * OvS/OvN conference is happening in a few weeks, and Aaron is working on finalizing his talk etc. so he will be fairly busy in the next few weeks. ===================================================================== CI Status --------------------------------------------------------------------- AWS Lab * None --------------------------------------------------------------------- UNH-IOL Community Lab * Pw-ci * UNH experimenting with a jenkins_mon jenkins provider for CI testing in the pw-ci framework * Patrick provided a review back to Aaron for the initial pw-ci port from Bash to Python * Open question about having a distinct jenkins_mon (current attempt from UNH) vs handling everything on 1 Jenkins machine * We started running new DTS testsuites on E810 on Arm Grace a couple weeks ago - there have been some failures (not really DTS related) where the network interfaces will not bind to DPDK or kernel drivers. We rebooted the system and send in retests yesterday. * We are standing up a dev version of a new results dashboard which we are using broadly at UNH (beyond the DPDK project) and pushing DPDK results to it. There are some remaining requirements for the DPDK project which we are working on providing via this dashboard. --------------------------------------------------------------------- Intel Lab * None --------------------------------------------------------------------- Github Actions Robot * In Q1 of next year, Aaron will be working to upgrade their current bash based instance of pw-ci to python scripting * Need to update the label for the post results script. * Proposing a new format for reporting the direct URLs to the results page. --------------------------------------------------------------------- Loongson Lab * None ===================================================================== DTS Improvements & Test Development * Mbuf_fast_free testcase is merged * Single_core_forward_perf: * Andrew is providing a review * Dean has tested the series. * Dean can you add a tested-by tag if you are done? * UNH lab to pick up moving over more of the existing framework calls to the testsuite API * Virtio testsuite: * Fully virtual testsuites look good * Physical virtual physical testsuite is showing more packets forwarded than expected. Dean is reviewing whether packets are being looped or similar. * QinQ testsuite: * New version sent on Friday ===================================================================== Any other business * Next Meeting is Nov 13, 2025 * The November 27 meeting is on American Thanksgiving, so it will be cancelled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugzilla at dpdk.org Wed Nov 5 10:27:11 2025 From: bugzilla at dpdk.org (bugzilla at dpdk.org) Date: Wed, 05 Nov 2025 09:27:11 +0000 Subject: [lab/job scripts Bug 1532] Windows Server 2022 misses the Mlx5DevX library installation In-Reply-To: References: Message-ID: http://bugs.dpdk.org/show_bug.cgi?id=1532 mkashani at nvidia.com (mkashani at nvidia.com) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |mkashani at nvidia.com Resolution|--- |WONTFIX --- Comment #4 from mkashani at nvidia.com (mkashani at nvidia.com) --- missing header -- You are receiving this mail because: You are the assignee for the bug. From bugzilla at dpdk.org Wed Nov 5 15:14:59 2025 From: bugzilla at dpdk.org (bugzilla at dpdk.org) Date: Wed, 05 Nov 2025 14:14:59 +0000 Subject: [lab/job scripts Bug 1532] Windows Server 2022 misses the Mlx5DevX library installation In-Reply-To: References: Message-ID: http://bugs.dpdk.org/show_bug.cgi?id=1532 Thomas Monjalon (thomas at monjalon.net) changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|RESOLVED |CONFIRMED Resolution|WONTFIX |--- CC| |thomas at monjalon.net --- Comment #5 from Thomas Monjalon (thomas at monjalon.net) --- mlx5 is supposed to compile on Windows with MSVC and clang. Please check again what is missing in the install. -- You are receiving this mail because: You are the assignee for the bug. From probb at iol.unh.edu Thu Nov 6 20:50:37 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 6 Nov 2025 14:50:37 -0500 Subject: Intel doc built failure in DPDK CI testing Message-ID: Hello, I recently submitted a patchseries to DPDK, which Intel DPDK Lab is reporting a build failure for: failure email: https://mails.dpdk.org/archives/test-report/2025-November/927503.html series: https://patchwork.dpdk.org/project/dpdk/list/?series=36596 failure: --------------- *Build Failed #1: OS: UB2404-64 Target: x86_64-native-linuxapp-doc FAILED: doc/guides/html /usr/bin/python3 ../buildtools/call-sphinx-build.py /usr/bin/sphinx-build 25.11.0-rc1 /root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/doc/guides /root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/x86_64-native-linuxapp-doc/doc/guides -a -W Warning, treated as error: /root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/doc/guides/tools/dts.rst:555:Include file '/root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/dts/test_run.example.yaml' not found or reading it failed [3674/3674] Generating doc/api/dts/dts_api_html with a custom command ninja: build stopped -------------------- The above says the failure is caused because dpdk/dts/test_run.example.yaml is not found, and it is referenced in line 555 of dts.rst. That makes sense, given that dts/test_run.example.yaml is removed in my series, and moved into a new directory (dts/configuration). So, now the path for this file is dts/configuration/test_run.example.yaml. However, this should not be an issue for the build, because dts.rest is updated in my patchseries to reflect the new configuration paths. See: https://patchwork.dpdk.org/project/dpdk/patch/20251105223628.1659390-3-probb at iol.unh.edu/ diff: @@ -549,20 +576,20 @@ And they both have two network ports which are physically connected to each othe .. _test_run_configuration_example: -``dts/test_run.example.yaml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``dts/configurations/test_run.example.yaml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. literalinclude:: ../../../dts/test_run.example.yaml +.. literalinclude:: ../../../dts/configurations/test_run.example.yaml :language: yaml :start-at: # Define The diff above which is a part of my series should be ensuring that the reference to dts/test_run.example.yaml is removed, but it is clearly still remaining in the DPDK artifact you are using for your build for testing. Can you check this, and check whether my patch is being properly applied before the doc build starts? Please let me know if I am making any errors, I am happy to re-submit differently as needed! Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aconole at redhat.com Fri Nov 7 14:48:41 2025 From: aconole at redhat.com (Aaron Conole) Date: Fri, 07 Nov 2025 08:48:41 -0500 Subject: Intel doc built failure in DPDK CI testing In-Reply-To: (Patrick Robb's message of "Thu, 6 Nov 2025 14:50:37 -0500") References: Message-ID: Patrick Robb writes: > Hello, > > I recently submitted a patchseries to DPDK, which Intel DPDK Lab is reporting a build failure > for: > > failure email: https://mails.dpdk.org/archives/test-report/2025-November/927503.html > series: https://patchwork.dpdk.org/project/dpdk/list/?series=36596 NOTE that you'll need to respin the series anyway due to SPDX failure. BUT, I agree something might be amiss in the intel setup - the doc build in github actions passed: https://github.com/ovsrobot/dpdk/actions/runs/19119065633/job/54635284364 > failure: > > --------------- > > *Build Failed #1: > OS: UB2404-64 > Target: x86_64-native-linuxapp-doc > FAILED: doc/guides/html > /usr/bin/python3 ../buildtools/call-sphinx-build.py /usr/bin/sphinx-build 25.11.0-rc1 > /root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/doc/guides > /root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/x86_64-native-linuxapp-doc/doc/guides > -a -W > > Warning, treated as error: > /root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/doc/guides/tools/dts.rst:555:Include > file > '/root/UB2404-64_K6.8.0_GCC13.3.0/x86_64-native-linuxapp-doc/36596/dpdk/dts/test_run.example.yaml' > not found or reading it failed > [3674/3674] Generating doc/api/dts/dts_api_html with a custom command > ninja: build stopped > > -------------------- > > The above says the failure is caused because dpdk/dts/test_run.example.yaml is not found, > and it is referenced in line 555 of dts.rst. That makes sense, given that > dts/test_run.example.yaml is removed in my series, and moved into a new directory > (dts/configuration). So, now the path for this file is > dts/configuration/test_run.example.yaml. However, this should not be an issue for the > build, because dts.rest is updated in my patchseries to reflect the new configuration paths. > See: > https://patchwork.dpdk.org/project/dpdk/patch/20251105223628.1659390-3-probb at iol.unh.edu/ > > > diff: > > @@ -549,20 +576,20 @@ And they both have two network ports which are physically > connected to each othe > > .. _test_run_configuration_example: > > -``dts/test_run.example.yaml`` > -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +``dts/configurations/test_run.example.yaml`` > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -.. literalinclude:: ../../../dts/test_run.example.yaml > +.. literalinclude:: ../../../dts/configurations/test_run.example.yaml > :language: yaml > :start-at: # Define > > > The diff above which is a part of my series should be ensuring that the reference to > dts/test_run.example.yaml is removed, but it is clearly still remaining in the DPDK artifact > you are using for your build for testing. Can you check this, and check whether my patch is > being properly applied before the doc build starts? Please let me know if I am making any > errors, I am happy to re-submit differently as needed! > > Thanks. From probb at iol.unh.edu Wed Nov 12 22:30:37 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Wed, 12 Nov 2025 16:30:37 -0500 Subject: [*SPAM*] Windows DPDK Build Help In-Reply-To: <20251112011352.GA5495@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20251112011352.GA5495@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Message-ID: Thanks, I'll try these new steps and check what the default compiler is (according to meson). What should the name of the msvc compiler be (in meson)? I'm guessing it's not Clang, hah. Anyhow, I recall we can override this with environment variables if we need to. Thanks. On Tue, Nov 11, 2025 at 8:13?PM Andre Muezerie wrote: > On Mon, Nov 10, 2025 at 03:14:54PM -0800, Patrick Robb wrote: > > Hi Andre, > > > > At the DPDK Community Lab we are setting up a new windows build machine, > > which is a windows server 2025 VM. When this is ready we will retire our > > windows server 2022 VM which is running in CI currently. > > > > We also want to ensure that the new machine is picking up devx in the > build > > per https://doc.dpdk.org/guides/platform/mlx5.html > > > > And we want to support the 3 compiler toolchains explained here: > > https://doc.dpdk.org/guides/windows_gsg/ > > > > First, I'll note that we are able to build DPDK, including mlnx devx inc > > and lib successfully with Clang. So, that toolchain is all set. > > > > However, we also want to do a native build on Windows using MSVC. Per the > > instructions from the page above, we are following this procedure: > > > > 1. Open Powershell > > 2. Launch VsDevCmd.bat > > 3. meson setup with -Dstd_atomic=true > > 4. Build DPDK > > > > However, when I run meson setup, it indicates that Clang is the compiler. > > This is incorrect, right? Do I need to modify an env variable to set the > > compiler to MSVC? Here is the start of the meson setup if that helps > > clarify the situation: > > > > PS C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools> > > ./VsDevCmd.bat -arch=amd64 > > ********************************************************************** > > ** Visual Studio 2022 Developer Command Prompt v17.14.17 > > ** Copyright (c) 2025 Microsoft Corporation > > ********************************************************************** > > PS C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools> > > cd / > > PS C:\> cd .\Users\ > > PS C:\Users> cd .\Administrator\ > > PS C:\Users\Administrator> cd .\Documents\ > > PS C:\Users\Administrator\Documents> cd .\dpdk-new\ > > PS C:\Users\Administrator\Documents\dpdk-new> meson setup > > -Denable_stdatomic=true build38 > > The Meson build system > > Version: 1.9.1 > > Source dir: C:\Users\Administrator\Documents\dpdk-new > > Build dir: C:\Users\Administrator\Documents\dpdk-new\build38 > > Build type: native build > > Project name: DPDK > > Project version: 25.11.0-rc1 > > C compiler for the host machine: clang (clang 17.0.1 "clang version > 17.0.1") > > C linker for the host machine: clang link 14.44.35217.0 > > Host machine cpu family: x86_64 > > > > > > > > Do you see any errors in my setup? Thanks Andre. > > > > -- > > > > Patrick Robb > > > > Open Source Labs Manager > > > > UNH Interoperability Labs > > > > 21 Madbury Rd, Suite 100, Durham, NH 03824 > > > > www.iol.unh.edu > > > Hi Patrick, > > I'm glad to hear that a Windows Server 2025 VM will be used to build DPDK > using > the 3 compilers. > > Good catch in finding that issue with the build. I never hit that because > I always > use CMD instead of Powershell, but I see that the link mentioned in the > documentation might induce people to run the .bat script from PS. I'll fix > that. > > To get things working, this is my recommendation: just replace step (1) > with: > > 1. Open cmd > > Alternatively, if you really want to use Powershell you can call a PS > flavor of > that script: > > 1. Open Powershell > 2. & "C:\Program Files\Microsoft Visual > Studio\2022\Enterprise\Common7\Tools\Launch-VsDevShell.ps1" -HostArch amd64 > -Arch amd64 > > You might have to fix the location where the script is stored. It's stored > in > the same location as VsDevCmd.bat. > > After making this change please confirm the correct compiler is called, > like you did before. > > Thanks, > > Andre Muezerie > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andremue at linux.microsoft.com Thu Nov 13 15:41:19 2025 From: andremue at linux.microsoft.com (Andre Muezerie) Date: Thu, 13 Nov 2025 06:41:19 -0800 Subject: [*SPAM*] Windows DPDK Build Help In-Reply-To: References: <20251112011352.GA5495@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Message-ID: <20251113144119.GA26285@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> On Wed, Nov 12, 2025 at 04:30:37PM -0500, Patrick Robb wrote: > Thanks, I'll try these new steps and check what the default compiler is > (according to meson). > > What should the name of the msvc compiler be (in meson)? I'm guessing it's > not Clang, hah. Anyhow, I recall we can override this with environment > variables if we need to. > Not Clang :-) On my machine this is what shows up: C compiler for the host machine: cl (msvc 19.44.35220 "Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35220 for x64") C linker for the host machine: link link 14.44.35220.0 You should get something similar to this. > Thanks. > > On Tue, Nov 11, 2025 at 8:13?PM Andre Muezerie > wrote: > > > On Mon, Nov 10, 2025 at 03:14:54PM -0800, Patrick Robb wrote: > > > Hi Andre, > > > > > > At the DPDK Community Lab we are setting up a new windows build machine, > > > which is a windows server 2025 VM. When this is ready we will retire our > > > windows server 2022 VM which is running in CI currently. > > > > > > We also want to ensure that the new machine is picking up devx in the > > build > > > per https://doc.dpdk.org/guides/platform/mlx5.html > > > > > > And we want to support the 3 compiler toolchains explained here: > > > https://doc.dpdk.org/guides/windows_gsg/ > > > > > > First, I'll note that we are able to build DPDK, including mlnx devx inc > > > and lib successfully with Clang. So, that toolchain is all set. > > > > > > However, we also want to do a native build on Windows using MSVC. Per the > > > instructions from the page above, we are following this procedure: > > > > > > 1. Open Powershell > > > 2. Launch VsDevCmd.bat > > > 3. meson setup with -Dstd_atomic=true > > > 4. Build DPDK > > > > > > However, when I run meson setup, it indicates that Clang is the compiler. > > > This is incorrect, right? Do I need to modify an env variable to set the > > > compiler to MSVC? Here is the start of the meson setup if that helps > > > clarify the situation: > > > > > > PS C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools> > > > ./VsDevCmd.bat -arch=amd64 > > > ********************************************************************** > > > ** Visual Studio 2022 Developer Command Prompt v17.14.17 > > > ** Copyright (c) 2025 Microsoft Corporation > > > ********************************************************************** > > > PS C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools> > > > cd / > > > PS C:\> cd .\Users\ > > > PS C:\Users> cd .\Administrator\ > > > PS C:\Users\Administrator> cd .\Documents\ > > > PS C:\Users\Administrator\Documents> cd .\dpdk-new\ > > > PS C:\Users\Administrator\Documents\dpdk-new> meson setup > > > -Denable_stdatomic=true build38 > > > The Meson build system > > > Version: 1.9.1 > > > Source dir: C:\Users\Administrator\Documents\dpdk-new > > > Build dir: C:\Users\Administrator\Documents\dpdk-new\build38 > > > Build type: native build > > > Project name: DPDK > > > Project version: 25.11.0-rc1 > > > C compiler for the host machine: clang (clang 17.0.1 "clang version > > 17.0.1") > > > C linker for the host machine: clang link 14.44.35217.0 > > > Host machine cpu family: x86_64 > > > > > > > > > > > > Do you see any errors in my setup? Thanks Andre. > > > > > > -- > > > > > > Patrick Robb > > > > > > Open Source Labs Manager > > > > > > UNH Interoperability Labs > > > > > > 21 Madbury Rd, Suite 100, Durham, NH 03824 > > > > > > www.iol.unh.edu > > > > > > Hi Patrick, > > > > I'm glad to hear that a Windows Server 2025 VM will be used to build DPDK > > using > > the 3 compilers. > > > > Good catch in finding that issue with the build. I never hit that because > > I always > > use CMD instead of Powershell, but I see that the link mentioned in the > > documentation might induce people to run the .bat script from PS. I'll fix > > that. > > > > To get things working, this is my recommendation: just replace step (1) > > with: > > > > 1. Open cmd > > > > Alternatively, if you really want to use Powershell you can call a PS > > flavor of > > that script: > > > > 1. Open Powershell > > 2. & "C:\Program Files\Microsoft Visual > > Studio\2022\Enterprise\Common7\Tools\Launch-VsDevShell.ps1" -HostArch amd64 > > -Arch amd64 > > > > You might have to fix the location where the script is stored. It's stored > > in > > the same location as VsDevCmd.bat. > > > > After making this change please confirm the correct compiler is called, > > like you did before. > > > > Thanks, > > > > Andre Muezerie > > From bugzilla at dpdk.org Wed Nov 19 22:23:42 2025 From: bugzilla at dpdk.org (bugzilla at dpdk.org) Date: Wed, 19 Nov 2025 21:23:42 +0000 Subject: [lab/job scripts Bug 1532] Windows Server 2022 misses the Mlx5DevX library installation In-Reply-To: References: Message-ID: http://bugs.dpdk.org/show_bug.cgi?id=1532 Patrick Robb (probb at iol.unh.edu) changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Robb (probb at iol.unh.edu) --- Resolved: Now, both Clang and MSVC builds have meson picking up devx header and library in our CI builds. -- You are receiving this mail because: You are the assignee for the bug. From probb at iol.unh.edu Tue Nov 25 19:15:49 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Tue, 25 Nov 2025 13:15:49 -0500 Subject: ABI testing post 25.11 Message-ID: Hello tech board, I recall that earlier in the year, the ABI policy was being re-assessed. I do not recall if there was a conclusion to that discussion and a new policy. Is it still correct that once 25.11 is released the UNH lab should produce an ABI reference from it, and test patches for 26.03 and 26.07 against that ABI reference? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at monjalon.net Wed Nov 26 09:35:47 2025 From: thomas at monjalon.net (Thomas Monjalon) Date: Wed, 26 Nov 2025 09:35:47 +0100 Subject: ABI testing post 25.11 In-Reply-To: References: Message-ID: <3858067.Y6S9NjorxK@thomas> 25/11/2025 19:15, Patrick Robb: > Hello tech board, > > I recall that earlier in the year, the ABI policy was being re-assessed. I > do not recall if there was a conclusion to that discussion and a new policy. > > Is it still correct that once 25.11 is released the UNH lab should produce > an ABI reference from it, and test patches for 26.03 and 26.07 against that > ABI reference? Thanks. Yes, ABI for 26.03 must be compared with 25.11. And ABI for 26.07 must be compared with 26.03, in order to check with symbols added in 26.03.