From probb at iol.unh.edu Thu Oct 2 21:36:23 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 2 Oct 2025 15:36:23 -0400 Subject: Community CI Meeting Minutes - September 18 2025 Message-ID: ##################################################################### September 18, 2025 Attendees 1. Patrick Robb 2. Aaron Conole 3. Luca Vizzarro 4. Sadashiva Rao 5. Paul Szczepanek 6. Aaron Conole ##################################################################### Minutes ===================================================================== General Announcements * UNH guys met with governing board about the DTS work this year and priorities going forward in remaining 2025 time and in 2026 (pending next contract). * We have published the new DTS instructional videos, showing how to setup and run the framework, and how to write a testcase. * Should produce a part 2 video soon showing some of the minor details like how to use the logger etc. * OvS conference: Call for papers now, ending Monday CI Status --------------------------------------------------------------------- AWS Lab * None --------------------------------------------------------------------- UNH-IOL Community Lab * PW-CI: Working on standing up an instance of pw-ci, so we can start to poll for some patches and better understand if this can be used in our lab * Adam made a graphic about how pw-ci works and sent it to Aaron to see whether our understanding is correct * It could also be committed to the repo if that was considered a value * DTS: * Mlx5_core: A patch has been merged which changes how the device reports MTU, causing the MTU DTS testsuite to fail. Patrick needs to check what the issue is and send the info to the submitter. * Sadashiva asked what platforms/tests are being run at the community lab: * Intel i40e and ice testing: * Performance: * Single core forwarding test * Functional testing: * Various ethdev tests found in https://git.dpdk.org/tools/dts/tree/tests * Cryptodev testing: * Still using legacy DTS for this * Patrick to send a summary to Satashiva for Intel based testing at the Community Lab --------------------------------------------------------------------- Intel Lab * None --------------------------------------------------------------------- Github Actions Robot * Aaron has sent out to a few CI people an initial patch porting pw-ci over to Python. * Adam and Patrick from UNH will do a review * Coderabbit and sourcery.ai: * Reporting into DPDK patchwork * Consensus from tech board is that it is sometimes catching issues, but also making a lot of ?noise.? Unclear whether it is a positive or negative value. * Possibly going to disable coderabbit for now and enable a competing system. --------------------------------------------------------------------- Loongson Lab * None ===================================================================== DTS Improvements & Test Development * Aaron?s AI CI systems are sending some reviews for DTS patches: * https://github.com/ovsrobot/dpdk/pull/49 * DTS API Series: * Looks good. Patrick to merge. * Want to ensure that there are no bugs introduced to testsuites through this patch. UNH guys to run testing on our hardware. * Testsuite docs: https://patchwork.dpdk.org/project/dpdk/patch/20250910194259.1027220-2-paul.szczepanek at arm.com/ * Depends on the API update series, which is being merged today. * Virtio testing: Dean is working on a virtio forwarding testsuite to start * Contains virtio testing testcases both with the backend vhost in ?no-pci mode and also others that have the backend vhost forward packets from physical NICs * V1 Submitted. * Single_core_forwarding * Different drivers require different testpmd flags to optimize performance. So, reading SUT node config from get_ctx() and switching testpmd args based on this. * Without this change, some NICs will perform below their forwarding baseline * Build args for Intel: * Intel uses a special flag for the rx descriptor byte size, which would need to be included in the user?s test_run.yaml for the SUT to build ?correctly.? * https://patchwork.dpdk.org/project/dpdk/patch/20250910122749.8277-1-abailey at iol.unh.edu/ * We need to refactor the bound_for_kernel logic * Patrick needs to do a review the v5 * Patrick to do a review for the tx_offload framework support and the mbuf_fast_free series * https://patchwork.dpdk.org/project/dpdk/list/?series=36153 * Tech board is still discussing the right default behavior for mbuf_fast_free, which will determine how the testcase should be written Any other business * Next Meeting is Oct 2, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Thu Oct 2 21:57:57 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 2 Oct 2025 15:57:57 -0400 Subject: DTS WG Meeting Minutes - September 25, 2025 Message-ID: #################################################################### September 25, 2025 Attendees * Patrick Robb * Luca Vizzarro * Andrew Bailey * Paul Szczepanek * Indira K #################################################################### Minutes ===================================================================== General Discussion * DTS Videos links: * How to set up and run DTS: https://www.youtube.com/watch?v=vxii8pboNAI&pp=ygUHdW5oIGlvbA%3D%3D * How to write a testsuite: https://www.youtube.com/watch?v=3w9XrYtTvqE&pp=ygUHdW5oIGlvbA%3D%3D ===================================================================== Patch discussions * Recently merged: * DTS API * Testsuite Docstrings update * TG Driver Bind * RSS: * Dean is currently testing/reviewing * Mbuf fast release testcase / tx_offload: * Framework changes look to be almost done. * Virtio: * V1 is sent * Patrick Robb to do a test/review * Single_core_fwd_perf: * Need to rebase on main before submitting the next version because of the DTS API patch * Need to ensure the docstrings are compliant with the current testsuites docstring structure * 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 * Paul notes for next release we should implement an API freeze for DTS * Next meeting is Oct 9, 2025 * We are still inheriting from TestSuite, which is an internal framework object which should not be imported. Maybe the most reasonable thing would be for the API to have a class/interface * Add a TestSuite class to API which inherits from protocol, with set up test suite, set up test case methods etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Thu Oct 2 21:59:37 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 2 Oct 2025 15:59:37 -0400 Subject: Community CI Meeting Minutes - October 2, 2025 Message-ID: ##################################################################### October 2, 2025 Attendees 1. Patrick Robb 2. Luca Vizzarro 3. Paul Szczepanek 4. Andrew Bailey 5. Aaron Conole ##################################################################### Minutes ===================================================================== General Announcements * There is a new member of the DTS slack, Zack Vonler, who is implementing a new PMD and would like to use DTS to validate his new PMD is conforming to DPDK ===================================================================== CI Status --------------------------------------------------------------------- AWS Lab * None --------------------------------------------------------------------- UNH-IOL Community Lab * PW-CI: Working on standing up an instance of pw-ci, so we can start to poll for some patches and better understand if this can be used in our lab * Adam and Patrick still need to stand up a working instance of the current (bash) pw-ci * Aaron has noted that he wants to decouple the components used for entering results into the DB and the component involved in sending reports * Aaron can help if we are stuck with the setup. * We can add some additional documentation based on this (if indeed there is missing info) * Windows server 2025: * We are moving over the 3 compiler toolchains and automated builds to the new Windows server VM * Missing stdin on some log files: * Addin stdin to log files where that is missing (i.e. make sure to capture meson args used in setup) * Mbuf_fast_free * Patrick needs to make sure we are able to add in the manual enable of mbuf fast release when the default behavior (changing from default on to default off) is modified in dpdk main --------------------------------------------------------------------- Intel Lab * Sadashiva Rao is a new contact that we should CC on discussions relating to the Intel lab. Github Actions Robot * Coderabbit feedback: * It is a mixed bag. Sometimes it can catch real issues, and other times it makes suggestions that are just nitpicking, and other times the feedback is just ?nonsense.? There is some discussion about moving to a different tool * David submitted a patch in an attempt to tailor it further * It is tailored through an entry YAML * If the project is moving away from coderabbit anyways, it?s unclear whether it makes sense to add a coderabbit artifact to the tree. * Sourcery was not very useful * Cirrus CI: * On David?s fork, he used it for freebsd build testing * Aaron is working on porting the pw-ci project from bash scripts to Python --------------------------------------------------------------------- Loongson Lab * None ===================================================================== DTS Improvements & Test Development * Tx offloads * Is reviewed by Luca * V6 is out * Patrick and Andrew to look at this together. * Single core forwarding test * V4 is sent out * There is a blocker for enabling mbuf_fast_free here, due to a dependency on the tx_offloads series. * When that series is merged, I will rebase, send a v5 with mbuf_fast_free enabled * Most of Luca?s comments from the V3 should be resolved. * Default params: I think that we should encourage testsuite writers to always include defaults for the testsuite specific params, and allow users to override those values from tests_config.yaml as needed. * Right now, after running all packet combinations, we print a big table at the end in the console. But, we are not writing this to a file in /output/single_core_forwarding. Patrick to add some structured file here to store the latest MPPS results. * RSS * For debugging, Dean is printing the predicted table, the RETA table returned by testpmd, and all the packet/queue combos to understand whether the testsuite is failing due to the mellanox PMD/device or because of our python code * Virtio/Vhost * Dean is writing a v2 based on Luca?s comments * Patrick needs to do a review * QinQ: * We still need to collect the Broadcom results * Should be able to merge soon after sharing those out ===================================================================== Any other business * Next Meeting is Oct 16, 2025 * DPDK RC1 is out next week, so let?s keep it up on reviews :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.mcnamara at intel.com Wed Oct 15 11:53:31 2025 From: john.mcnamara at intel.com (Mcnamara, John) Date: Wed, 15 Oct 2025 09:53:31 +0000 Subject: DPDK Coverity Build tool version is no longer supported Message-ID: Hi, There is an issue with the DPDK Coverity: https://scan.coverity.com/projects/dpdk-data-plane-development-kit The error message on the landing page says: * Last Build Status: Failed. Your build has failed due to the following reason. * Please fix the error and upload the build again. * Error details: The Coverity Build tool version is no longer supported. * Please download the latest version for your platform from https://scan.coverity.com/download John -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhoumin at loongson.cn Thu Oct 16 11:09:48 2025 From: zhoumin at loongson.cn (Min Zhou) Date: Thu, 16 Oct 2025 17:09:48 +0800 Subject: [PATCH v1] maintainers: update for LoongArch Message-ID: <20251016090948.836029-1-zhoumin@loongson.cn> Update maintainers for LoongArch architecture. Signed-off-by: Min Zhou Signed-off-by: Bibo Mao --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1a2729be66..7abe482e7d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -320,7 +320,7 @@ F: examples/*/*_neon.* F: examples/common/neon/ LoongArch -M: Min Zhou +M: Bibo Mao F: config/loongarch/ F: doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst F: lib/eal/loongarch/ -- 2.27.0 From probb at iol.unh.edu Thu Oct 16 13:32:02 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 16 Oct 2025 07:32:02 -0400 Subject: [PATCH v1] maintainers: update for LoongArch In-Reply-To: <20251016090948.836029-1-zhoumin@loongson.cn> References: <20251016090948.836029-1-zhoumin@loongson.cn> Message-ID: Hi Min Zhou, Will Bibi be responsible for maintaining the Loongarch CI testing going forward, or are you retaining that responsibility? Thanks. On Thu, Oct 16, 2025 at 5:46?AM Min Zhou wrote: > Update maintainers for LoongArch architecture. > > Signed-off-by: Min Zhou > Signed-off-by: Bibo Mao > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1a2729be66..7abe482e7d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -320,7 +320,7 @@ F: examples/*/*_neon.* > F: examples/common/neon/ > > LoongArch > -M: Min Zhou > +M: Bibo Mao > F: config/loongarch/ > F: doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst > F: lib/eal/loongarch/ > -- > 2.27.0 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhoumin at loongson.cn Thu Oct 16 14:30:14 2025 From: zhoumin at loongson.cn (zhoumin) Date: Thu, 16 Oct 2025 20:30:14 +0800 Subject: [PATCH v1] maintainers: update for LoongArch In-Reply-To: References: <20251016090948.836029-1-zhoumin@loongson.cn> Message-ID: Hi Patrick Robb, Yes, Bibo will also be responsible for maintaining the LoongArch CI testing going forward. On Thu, Oct 16, 2025 at 7:32 PM, Patrick Robb wrote: > Hi Min Zhou, > > Will Bibi be responsible for maintaining the Loongarch CI testing > going forward, or are you retaining that responsibility? Thanks. > > On Thu, Oct 16, 2025 at 5:46?AM Min Zhou > wrote: > > Update maintainers for LoongArch architecture. > > Signed-off-by: Min Zhou > > Signed-off-by: Bibo Mao > > --- > ?MAINTAINERS | 2 +- > ?1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1a2729be66..7abe482e7d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -320,7 +320,7 @@ F: examples/*/*_neon.* > ?F: examples/common/neon/ > > ?LoongArch > -M: Min Zhou > > +M: Bibo Mao > > ?F: config/loongarch/ > ?F: doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst > ?F: lib/eal/loongarch/ > -- > 2.27.0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maobibo at loongson.cn Thu Oct 16 14:40:54 2025 From: maobibo at loongson.cn (Bibo Mao) Date: Thu, 16 Oct 2025 20:40:54 +0800 Subject: [PATCH v1] maintainers: update for LoongArch In-Reply-To: References: <20251016090948.836029-1-zhoumin@loongson.cn> Message-ID: On 2025/10/16 ??8:30, zhoumin wrote: > Hi Patrick Robb, > > Yes, Bibo will also be responsible for maintaining the LoongArch CI > testing going forward. I will be responsible for maintaining the LoongArch CI also, and best wishes and thanks for contribution for Min Zhou. Regards Bibo Mao > > On Thu, Oct 16, 2025 at 7:32 PM, Patrick Robb wrote: >> Hi Min Zhou, >> >> Will Bibi be responsible for maintaining the Loongarch CI testing >> going forward, or are you retaining that responsibility? Thanks. >> >> On Thu, Oct 16, 2025 at 5:46?AM Min Zhou > > wrote: >> >> Update maintainers for LoongArch architecture. >> >> Signed-off-by: Min Zhou > > >> Signed-off-by: Bibo Mao > > >> --- >> ?MAINTAINERS | 2 +- >> ?1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 1a2729be66..7abe482e7d 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -320,7 +320,7 @@ F: examples/*/*_neon.* >> ?F: examples/common/neon/ >> >> ?LoongArch >> -M: Min Zhou > >> +M: Bibo Mao > >> ?F: config/loongarch/ >> ?F: doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst >> ?F: lib/eal/loongarch/ >> -- >> 2.27.0 >> From probb at iol.unh.edu Thu Oct 16 19:49:38 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 16 Oct 2025 13:49:38 -0400 Subject: [PATCH v1] maintainers: update for LoongArch In-Reply-To: References: <20251016090948.836029-1-zhoumin@loongson.cn> Message-ID: Thank you Min Zhou for your contributions to DPDK CI Testing these past years. Welcome Bibo! On Thu, Oct 16, 2025 at 8:43?AM Bibo Mao wrote: > > > On 2025/10/16 ??8:30, zhoumin wrote: > > Hi Patrick Robb, > > > > Yes, Bibo will also be responsible for maintaining the LoongArch CI > > testing going forward. > I will be responsible for maintaining the LoongArch CI also, > and best wishes and thanks for contribution for Min Zhou. > > Regards > Bibo Mao > > > > On Thu, Oct 16, 2025 at 7:32 PM, Patrick Robb wrote: > >> Hi Min Zhou, > >> > >> Will Bibi be responsible for maintaining the Loongarch CI testing > >> going forward, or are you retaining that responsibility? Thanks. > >> > >> On Thu, Oct 16, 2025 at 5:46?AM Min Zhou >> > wrote: > >> > >> Update maintainers for LoongArch architecture. > >> > >> Signed-off-by: Min Zhou >> > > >> Signed-off-by: Bibo Mao >> > > >> --- > >> MAINTAINERS | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index 1a2729be66..7abe482e7d 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -320,7 +320,7 @@ F: examples/*/*_neon.* > >> F: examples/common/neon/ > >> > >> LoongArch > >> -M: Min Zhou > > >> +M: Bibo Mao > > >> F: config/loongarch/ > >> F: doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst > >> F: lib/eal/loongarch/ > >> -- > >> 2.27.0 > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at monjalon.net Sun Oct 19 22:52:33 2025 From: thomas at monjalon.net (Thomas Monjalon) Date: Sun, 19 Oct 2025 22:52:33 +0200 Subject: [PATCH] dmadev: replace zero length array In-Reply-To: References: <20251015185946.338417-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35F654D4@smartserver.smartshare.dk> Message-ID: <4229816.eFTFzoEnKi@thomas> 16/10/2025 11:50, Pavan Nikhilesh Bhagavatula: > > From: Bruce Richardson [mailto:bruce.richardson at intel.com] > >> On Wed, Oct 15, 2025 at 11:59:46AM -0700, Stephen Hemminger wrote: > >> > - struct rte_dma_sge src_dst_seg[0]; > >> > + struct rte_dma_sge src_dst_seg[]; > >> > > >> Acked-by: Bruce Richardson > >Acked-by: Morten Br?rup > > Thanks Stephan, > > Acked-by: Pavan Nikhilesh Bhagavatula Applied, thanks. > We should probably add this check to CI. Yes From probb at iol.unh.edu Thu Oct 23 01:05:15 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Wed, 22 Oct 2025 19:05:15 -0400 Subject: BNXT patches In-Reply-To: References: Message-ID: Hi Ajit, That sounds annoying. A sanity check question to start - is there any sense in resubmitting the series and just intentionally delaying sending the 2nd half of the commits? I.e. 1. git send-email /my-patches-dir/* 2. Send the first 30 3. At prompt for 31st patch, pause. 4. wait 10 minutes. 5. Return to terminal, send patches 31 through 57. Or, if this is not possible, I think there should be some solution on the patchwork mail server policy side. I think Ali Alnubani from NVIDIA manages it and he is usually pretty responsive with such modification requests. We could ask about solutions like: 1. Add a complete exception to the mail server message rate restriction for emails coming from email addresses associated with DPDK member companies. or 2. Simply make the message rate restrictions more permissive than they are currently (i.e. allow 100 emails, not 30). If the ideas above will not work, I will have to assess the "bundle" idea tomorrow when I have time available than I do right now. Most likely it's technically possible to facilitate but I do feel like simply resolving the original issue (the mail server is not letting you submit your series) and allowing the CI system automation to intake the patchseries from patchwork in the normal way is the ideal approach. On Wed, Oct 22, 2025 at 5:39?PM Ajit Khaparde wrote: > Hi Patrick, > When Manish was submitting his patchset, > Looks like because of a mail server message rate restriction, > only 31 of 57 patches went through in the first attempt > > He submitted the remaining patches 32 to 57 in second attempt. > > I created a bundle for the series now. [1] > > Also a couple of patches were stuck at the gate. > So a proper build has not happened on the patchset yet. [2] > Do we have a way to trigger a build on the bundle? > > Please advise. > > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/ > [2] https://mails.dpdk.org/archives/test-report/2025-October/921500.html > > Thanks > Ajit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at monjalon.net Thu Oct 23 01:36:03 2025 From: thomas at monjalon.net (Thomas Monjalon) Date: Thu, 23 Oct 2025 01:36:03 +0200 Subject: BNXT patches In-Reply-To: References: Message-ID: <6873353.2l3rmUXbR5@thomas> Hello, Not related to CI, but the best would be to not wait a year for updating the driver in one series. As you maintain a repository branch, you can merge the patches and wait for UNH CI running on it. Also the GitHub robot can run if you push in a GitHub repo. 23/10/2025 01:05, Patrick Robb: > Hi Ajit, > > That sounds annoying. A sanity check question to start - is there any sense > in resubmitting the series and just intentionally delaying sending the 2nd > half of the commits? I.e. > > 1. git send-email /my-patches-dir/* > 2. Send the first 30 > 3. At prompt for 31st patch, pause. > 4. wait 10 minutes. > 5. Return to terminal, send patches 31 through 57. > > Or, if this is not possible, I think there should be some solution on the > patchwork mail server policy side. I think Ali Alnubani from NVIDIA manages > it and he is usually pretty responsive with such modification requests. We > could ask about solutions like: > > 1. Add a complete exception to the mail server message rate restriction for > emails coming from email addresses associated with DPDK member companies. > > or > > 2. Simply make the message rate restrictions more permissive than they are > currently (i.e. allow 100 emails, not 30). > > If the ideas above will not work, I will have to assess the "bundle" idea > tomorrow when I have time available than I do right now. Most likely it's > technically possible to facilitate but I do feel like simply resolving the > original issue (the mail server is not letting you submit your series) and > allowing the CI system automation to intake the patchseries from patchwork > in the normal way is the ideal approach. > > On Wed, Oct 22, 2025 at 5:39?PM Ajit Khaparde > wrote: > > > Hi Patrick, > > When Manish was submitting his patchset, > > Looks like because of a mail server message rate restriction, > > only 31 of 57 patches went through in the first attempt > > > > He submitted the remaining patches 32 to 57 in second attempt. > > > > I created a bundle for the series now. [1] > > > > Also a couple of patches were stuck at the gate. > > So a proper build has not happened on the patchset yet. [2] > > Do we have a way to trigger a build on the bundle? > > > > Please advise. > > > > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/ > > [2] https://mails.dpdk.org/archives/test-report/2025-October/921500.html > > > > Thanks > > Ajit From probb at iol.unh.edu Thu Oct 23 01:52:05 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Wed, 22 Oct 2025 19:52:05 -0400 Subject: BNXT patches In-Reply-To: <6873353.2l3rmUXbR5@thomas> References: <6873353.2l3rmUXbR5@thomas> Message-ID: That solution also makes sense. For the per-branch periodic testing page that Thomas is mentioning (here: https://lab.dpdk.org/results/dashboard/periodic_testing/) we are publishing regular test reports on next-net, but not next-net-brcm. But, it makes sense for us to start periodic runs on next-net-brcm, so I will add this now. It should only take a few minutes to add to our CI system. Then I will do a manual trigger which will add the first periodic testrun for next-net-brcm. Otherwise, it should run once every other day at midnight US eastern time. Let us know if this solution works for you Ajit. Thanks. On Wed, Oct 22, 2025 at 7:36?PM Thomas Monjalon wrote: > Hello, > > Not related to CI, but the best would be to not wait a year > for updating the driver in one series. > > As you maintain a repository branch, > you can merge the patches and wait for UNH CI running on it. > Also the GitHub robot can run if you push in a GitHub repo. > > > 23/10/2025 01:05, Patrick Robb: > > Hi Ajit, > > > > That sounds annoying. A sanity check question to start - is there any > sense > > in resubmitting the series and just intentionally delaying sending the > 2nd > > half of the commits? I.e. > > > > 1. git send-email /my-patches-dir/* > > 2. Send the first 30 > > 3. At prompt for 31st patch, pause. > > 4. wait 10 minutes. > > 5. Return to terminal, send patches 31 through 57. > > > > Or, if this is not possible, I think there should be some solution on the > > patchwork mail server policy side. I think Ali Alnubani from NVIDIA > manages > > it and he is usually pretty responsive with such modification requests. > We > > could ask about solutions like: > > > > 1. Add a complete exception to the mail server message rate restriction > for > > emails coming from email addresses associated with DPDK member companies. > > > > or > > > > 2. Simply make the message rate restrictions more permissive than they > are > > currently (i.e. allow 100 emails, not 30). > > > > If the ideas above will not work, I will have to assess the "bundle" idea > > tomorrow when I have time available than I do right now. Most likely it's > > technically possible to facilitate but I do feel like simply resolving > the > > original issue (the mail server is not letting you submit your series) > and > > allowing the CI system automation to intake the patchseries from > patchwork > > in the normal way is the ideal approach. > > > > On Wed, Oct 22, 2025 at 5:39?PM Ajit Khaparde < > ajit.khaparde at broadcom.com> > > wrote: > > > > > Hi Patrick, > > > When Manish was submitting his patchset, > > > Looks like because of a mail server message rate restriction, > > > only 31 of 57 patches went through in the first attempt > > > > > > He submitted the remaining patches 32 to 57 in second attempt. > > > > > > I created a bundle for the series now. [1] > > > > > > Also a couple of patches were stuck at the gate. > > > So a proper build has not happened on the patchset yet. [2] > > > Do we have a way to trigger a build on the bundle? > > > > > > Please advise. > > > > > > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/ > > > [2] > https://mails.dpdk.org/archives/test-report/2025-October/921500.html > > > > > > Thanks > > > Ajit > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.khaparde at broadcom.com Thu Oct 23 02:09:39 2025 From: ajit.khaparde at broadcom.com (Ajit Khaparde) Date: Wed, 22 Oct 2025 17:09:39 -0700 Subject: BNXT patches In-Reply-To: References: <6873353.2l3rmUXbR5@thomas> Message-ID: On Wed, Oct 22, 2025 at 4:52?PM Patrick Robb wrote: > > That solution also makes sense. Agree. Thanks Thomas. > > For the per-branch periodic testing page that Thomas is mentioning (here: https://lab.dpdk.org/results/dashboard/periodic_testing/) we are publishing regular test reports on next-net, but not next-net-brcm. But, it makes sense for us to start periodic runs on next-net-brcm, so I will add this now. It should only take a few minutes to add to our CI system. Then I will do a manual trigger which will add the first periodic testrun for next-net-brcm. Otherwise, it should run once every other day at midnight US eastern time. > > Let us know if this solution works for you Ajit. Thanks. Yes, Patrick, this should work. > > On Wed, Oct 22, 2025 at 7:36?PM Thomas Monjalon wrote: >> >> Hello, >> >> Not related to CI, but the best would be to not wait a year >> for updating the driver in one series. >> >> As you maintain a repository branch, >> you can merge the patches and wait for UNH CI running on it. >> Also the GitHub robot can run if you push in a GitHub repo. >> >> >> 23/10/2025 01:05, Patrick Robb: >> > Hi Ajit, >> > >> > That sounds annoying. A sanity check question to start - is there any sense >> > in resubmitting the series and just intentionally delaying sending the 2nd >> > half of the commits? I.e. >> > >> > 1. git send-email /my-patches-dir/* >> > 2. Send the first 30 >> > 3. At prompt for 31st patch, pause. >> > 4. wait 10 minutes. >> > 5. Return to terminal, send patches 31 through 57. >> > >> > Or, if this is not possible, I think there should be some solution on the >> > patchwork mail server policy side. I think Ali Alnubani from NVIDIA manages >> > it and he is usually pretty responsive with such modification requests. We >> > could ask about solutions like: >> > >> > 1. Add a complete exception to the mail server message rate restriction for >> > emails coming from email addresses associated with DPDK member companies. >> > >> > or >> > >> > 2. Simply make the message rate restrictions more permissive than they are >> > currently (i.e. allow 100 emails, not 30). >> > >> > If the ideas above will not work, I will have to assess the "bundle" idea >> > tomorrow when I have time available than I do right now. Most likely it's >> > technically possible to facilitate but I do feel like simply resolving the >> > original issue (the mail server is not letting you submit your series) and >> > allowing the CI system automation to intake the patchseries from patchwork >> > in the normal way is the ideal approach. >> > >> > On Wed, Oct 22, 2025 at 5:39?PM Ajit Khaparde >> > wrote: >> > >> > > Hi Patrick, >> > > When Manish was submitting his patchset, >> > > Looks like because of a mail server message rate restriction, >> > > only 31 of 57 patches went through in the first attempt >> > > >> > > He submitted the remaining patches 32 to 57 in second attempt. >> > > >> > > I created a bundle for the series now. [1] >> > > >> > > Also a couple of patches were stuck at the gate. >> > > So a proper build has not happened on the patchset yet. [2] >> > > Do we have a way to trigger a build on the bundle? >> > > >> > > Please advise. >> > > >> > > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/ >> > > [2] https://mails.dpdk.org/archives/test-report/2025-October/921500.html >> > > >> > > Thanks >> > > Ajit >> >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5479 bytes Desc: S/MIME Cryptographic Signature URL: From probb at iol.unh.edu Thu Oct 23 02:36:01 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Wed, 22 Oct 2025 20:36:01 -0400 Subject: BNXT patches In-Reply-To: References: <6873353.2l3rmUXbR5@thomas> Message-ID: There are multiple next-net-brcm branches at https://git.dpdk.org/next/dpdk-next-net-brcm/. I have chosen the for-next-net branch. Let me know if I should adjust. So, you can go to https://lab.dpdk.org/results/dashboard/periodic_testing/ and select the "showing branch" dropdown on the right and select "next-net-brcm-for-next-net" I kicked off a run from that branch so it should populate a new set of results within a couple hours. Then like I said a new run of that branch will kick off every 48 hours. Good luck! On Wed, Oct 22, 2025 at 8:09?PM Ajit Khaparde wrote: > On Wed, Oct 22, 2025 at 4:52?PM Patrick Robb wrote: > > > > That solution also makes sense. > Agree. Thanks Thomas. > > > > > For the per-branch periodic testing page that Thomas is mentioning > (here: https://lab.dpdk.org/results/dashboard/periodic_testing/) we are > publishing regular test reports on next-net, but not next-net-brcm. But, it > makes sense for us to start periodic runs on next-net-brcm, so I will add > this now. It should only take a few minutes to add to our CI system. Then I > will do a manual trigger which will add the first periodic testrun for > next-net-brcm. Otherwise, it should run once every other day at midnight US > eastern time. > > > > Let us know if this solution works for you Ajit. Thanks. > > Yes, Patrick, this should work. > > > > > On Wed, Oct 22, 2025 at 7:36?PM Thomas Monjalon > wrote: > >> > >> Hello, > >> > >> Not related to CI, but the best would be to not wait a year > >> for updating the driver in one series. > >> > >> As you maintain a repository branch, > >> you can merge the patches and wait for UNH CI running on it. > >> Also the GitHub robot can run if you push in a GitHub repo. > >> > >> > >> 23/10/2025 01:05, Patrick Robb: > >> > Hi Ajit, > >> > > >> > That sounds annoying. A sanity check question to start - is there any > sense > >> > in resubmitting the series and just intentionally delaying sending > the 2nd > >> > half of the commits? I.e. > >> > > >> > 1. git send-email /my-patches-dir/* > >> > 2. Send the first 30 > >> > 3. At prompt for 31st patch, pause. > >> > 4. wait 10 minutes. > >> > 5. Return to terminal, send patches 31 through 57. > >> > > >> > Or, if this is not possible, I think there should be some solution on > the > >> > patchwork mail server policy side. I think Ali Alnubani from NVIDIA > manages > >> > it and he is usually pretty responsive with such modification > requests. We > >> > could ask about solutions like: > >> > > >> > 1. Add a complete exception to the mail server message rate > restriction for > >> > emails coming from email addresses associated with DPDK member > companies. > >> > > >> > or > >> > > >> > 2. Simply make the message rate restrictions more permissive than > they are > >> > currently (i.e. allow 100 emails, not 30). > >> > > >> > If the ideas above will not work, I will have to assess the "bundle" > idea > >> > tomorrow when I have time available than I do right now. Most likely > it's > >> > technically possible to facilitate but I do feel like simply > resolving the > >> > original issue (the mail server is not letting you submit your > series) and > >> > allowing the CI system automation to intake the patchseries from > patchwork > >> > in the normal way is the ideal approach. > >> > > >> > On Wed, Oct 22, 2025 at 5:39?PM Ajit Khaparde < > ajit.khaparde at broadcom.com> > >> > wrote: > >> > > >> > > Hi Patrick, > >> > > When Manish was submitting his patchset, > >> > > Looks like because of a mail server message rate restriction, > >> > > only 31 of 57 patches went through in the first attempt > >> > > > >> > > He submitted the remaining patches 32 to 57 in second attempt. > >> > > > >> > > I created a bundle for the series now. [1] > >> > > > >> > > Also a couple of patches were stuck at the gate. > >> > > So a proper build has not happened on the patchset yet. [2] > >> > > Do we have a way to trigger a build on the bundle? > >> > > > >> > > Please advise. > >> > > > >> > > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/ > >> > > [2] > https://mails.dpdk.org/archives/test-report/2025-October/921500.html > >> > > > >> > > Thanks > >> > > Ajit > >> > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajit.khaparde at broadcom.com Fri Oct 24 05:24:45 2025 From: ajit.khaparde at broadcom.com (Ajit Khaparde) Date: Thu, 23 Oct 2025 20:24:45 -0700 Subject: BNXT patches In-Reply-To: References: <6873353.2l3rmUXbR5@thomas> Message-ID: On Wed, Oct 22, 2025 at 5:36?PM Patrick Robb wrote: > > There are multiple next-net-brcm branches at https://git.dpdk.org/next/dpdk-next-net-brcm/. I have chosen the for-next-net branch. Let me know if I should adjust. > > So, you can go to https://lab.dpdk.org/results/dashboard/periodic_testing/ and select the "showing branch" dropdown on the right and select "next-net-brcm-for-next-net" > > I kicked off a run from that branch so it should populate a new set of results within a couple hours. Then like I said a new run of that branch will kick off every 48 hours. Thanks, Patrick. This did help and looks like the build was cleaner than what we saw on the patchwork scorecard. > > Good luck! > > On Wed, Oct 22, 2025 at 8:09?PM Ajit Khaparde wrote: >> >> On Wed, Oct 22, 2025 at 4:52?PM Patrick Robb wrote: >> > >> > That solution also makes sense. >> Agree. Thanks Thomas. >> >> > >> > For the per-branch periodic testing page that Thomas is mentioning (here: https://lab.dpdk.org/results/dashboard/periodic_testing/) we are publishing regular test reports on next-net, but not next-net-brcm. But, it makes sense for us to start periodic runs on next-net-brcm, so I will add this now. It should only take a few minutes to add to our CI system. Then I will do a manual trigger which will add the first periodic testrun for next-net-brcm. Otherwise, it should run once every other day at midnight US eastern time. >> > >> > Let us know if this solution works for you Ajit. Thanks. >> >> Yes, Patrick, this should work. >> >> > >> > On Wed, Oct 22, 2025 at 7:36?PM Thomas Monjalon wrote: >> >> >> >> Hello, >> >> >> >> Not related to CI, but the best would be to not wait a year >> >> for updating the driver in one series. >> >> >> >> As you maintain a repository branch, >> >> you can merge the patches and wait for UNH CI running on it. >> >> Also the GitHub robot can run if you push in a GitHub repo. >> >> >> >> >> >> 23/10/2025 01:05, Patrick Robb: >> >> > Hi Ajit, >> >> > >> >> > That sounds annoying. A sanity check question to start - is there any sense >> >> > in resubmitting the series and just intentionally delaying sending the 2nd >> >> > half of the commits? I.e. >> >> > >> >> > 1. git send-email /my-patches-dir/* >> >> > 2. Send the first 30 >> >> > 3. At prompt for 31st patch, pause. >> >> > 4. wait 10 minutes. >> >> > 5. Return to terminal, send patches 31 through 57. >> >> > >> >> > Or, if this is not possible, I think there should be some solution on the >> >> > patchwork mail server policy side. I think Ali Alnubani from NVIDIA manages >> >> > it and he is usually pretty responsive with such modification requests. We >> >> > could ask about solutions like: >> >> > >> >> > 1. Add a complete exception to the mail server message rate restriction for >> >> > emails coming from email addresses associated with DPDK member companies. >> >> > >> >> > or >> >> > >> >> > 2. Simply make the message rate restrictions more permissive than they are >> >> > currently (i.e. allow 100 emails, not 30). >> >> > >> >> > If the ideas above will not work, I will have to assess the "bundle" idea >> >> > tomorrow when I have time available than I do right now. Most likely it's >> >> > technically possible to facilitate but I do feel like simply resolving the >> >> > original issue (the mail server is not letting you submit your series) and >> >> > allowing the CI system automation to intake the patchseries from patchwork >> >> > in the normal way is the ideal approach. >> >> > >> >> > On Wed, Oct 22, 2025 at 5:39?PM Ajit Khaparde >> >> > wrote: >> >> > >> >> > > Hi Patrick, >> >> > > When Manish was submitting his patchset, >> >> > > Looks like because of a mail server message rate restriction, >> >> > > only 31 of 57 patches went through in the first attempt >> >> > > >> >> > > He submitted the remaining patches 32 to 57 in second attempt. >> >> > > >> >> > > I created a bundle for the series now. [1] >> >> > > >> >> > > Also a couple of patches were stuck at the gate. >> >> > > So a proper build has not happened on the patchset yet. [2] >> >> > > Do we have a way to trigger a build on the bundle? >> >> > > >> >> > > Please advise. >> >> > > >> >> > > [1] https://patchwork.dpdk.org/bundle/ajitkhaparde/BNXT%2025.11/ >> >> > > [2] https://mails.dpdk.org/archives/test-report/2025-October/921500.html >> >> > > >> >> > > Thanks >> >> > > Ajit >> >> >> >> >> >> >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5479 bytes Desc: S/MIME Cryptographic Signature URL: From thomas at monjalon.net Fri Oct 24 15:54:26 2025 From: thomas at monjalon.net (Thomas Monjalon) Date: Fri, 24 Oct 2025 15:54:26 +0200 Subject: [PATCH v1] maintainers: update for LoongArch In-Reply-To: <20251016090948.836029-1-zhoumin@loongson.cn> References: <20251016090948.836029-1-zhoumin@loongson.cn> Message-ID: <2521648.VZ3vTMCxA0@thomas> 16/10/2025 11:09, Min Zhou: > LoongArch > -M: Min Zhou > +M: Bibo Mao > F: config/loongarch/ > F: doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst > F: lib/eal/loongarch/ Applied, thank you for the work done and to come. From bugzilla at dpdk.org Tue Oct 28 09:05:33 2025 From: bugzilla at dpdk.org (bugzilla at dpdk.org) Date: Tue, 28 Oct 2025 08:05:33 +0000 Subject: [lab/job scripts Bug 429] New Perf Test Case: Test above / below maximum throughput of NIC / system In-Reply-To: References: Message-ID: http://bugs.dpdk.org/show_bug.cgi?id=429 mkashani at nvidia.com (mkashani at nvidia.com) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkashani at nvidia.com Resolution|--- |WONTFIX Status|CONFIRMED |RESOLVED --- Comment #5 from mkashani at nvidia.com (mkashani at nvidia.com) --- old issue,closing -- You are receiving this mail because: You are the assignee for the bug. From david.marchand at redhat.com Fri Oct 31 09:38:32 2025 From: david.marchand at redhat.com (David Marchand) Date: Fri, 31 Oct 2025 09:38:32 +0100 Subject: Disable SPDK testing again? Message-ID: Hello, The SPDK target in UNH lab has been spewing warnings as SPDK build itself compiles and links against a list of libraries and drivers, regardless of the upstream dependencies. https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d74e8ff and https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66 Until SPDK fixes this on their side (either adding argparse in their static list, or using pkg-config for example and stopping patching DPDK), linking SPDK binaries fails as the argparse lib now necessary to EAL is not pulled: /usr/bin/ld.bfd: /usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o): in function `eal_usage': eal_common_options.c:(.text+0x16): undefined reference to `rte_argparse_print_help' /usr/bin/ld.bfd: /usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o): in function `eal_collate_args': eal_common_options.c:(.text+0x953): undefined reference to `rte_argparse_parse' /usr/bin/ld.bfd: /usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o): in function `eal_parse_args': eal_common_options.c:(.text+0x343b): undefined reference to `rte_argparse_parse_type' collect2: error: ld returned 1 exit status make[3]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.app.mk:39: spdk_lock] Error 1 make[2]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.subdirs.mk:16: lock] Error 2 make[1]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.subdirs.mk:16: thread] Error 2 While it is just a warning in the CI dashboard, I don't think we should waste resources on this testing. Opinions? -- David Marchand From mb at smartsharesystems.com Fri Oct 31 10:11:18 2025 From: mb at smartsharesystems.com (=?UTF-8?B?TW9ydGVuIEJyw7hydXA=?=) Date: Fri, 31 Oct 2025 10:11:18 +0100 Subject: Disable SPDK testing again? In-Reply-To: References: Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> > From: David Marchand [mailto:david.marchand at redhat.com] > Sent: Friday, 31 October 2025 09.39 > > Hello, > > The SPDK target in UNH lab has been spewing warnings as SPDK build > itself compiles and links against a list of libraries and drivers, > regardless of the upstream dependencies. > https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d7 > 4e8ff and > https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66 > > > Until SPDK fixes this on their side (either adding argparse in their > static list, or using pkg-config for example and stopping patching > DPDK), linking SPDK binaries fails as the argparse lib now necessary > to EAL is not pulled: > > /usr/bin/ld.bfd: > /usr/local/lib/x86_64-linux- > gnu/librte_eal.a(eal_common_eal_common_options.c.o): > in function `eal_usage': > eal_common_options.c:(.text+0x16): undefined reference to > `rte_argparse_print_help' > /usr/bin/ld.bfd: > /usr/local/lib/x86_64-linux- > gnu/librte_eal.a(eal_common_eal_common_options.c.o): > in function `eal_collate_args': > eal_common_options.c:(.text+0x953): undefined reference to > `rte_argparse_parse' > /usr/bin/ld.bfd: > /usr/local/lib/x86_64-linux- > gnu/librte_eal.a(eal_common_eal_common_options.c.o): > in function `eal_parse_args': > eal_common_options.c:(.text+0x343b): undefined reference to > `rte_argparse_parse_type' > collect2: error: ld returned 1 exit status > make[3]: *** [/root/workspace/Generic-DPDK-Compile- > Meson/spdk/mk/spdk.app.mk:39: > spdk_lock] Error 1 > make[2]: *** [/root/workspace/Generic-DPDK-Compile- > Meson/spdk/mk/spdk.subdirs.mk:16: > lock] Error 2 > make[1]: *** [/root/workspace/Generic-DPDK-Compile- > Meson/spdk/mk/spdk.subdirs.mk:16: > thread] Error 2 > > > While it is just a warning in the CI dashboard, I don't think we > should waste resources on this testing. > Opinions? We should ask ourselves why they are doing that. Is something wrong (or incomplete) with our handling of -Denable_libs? Are we including unnecessary optional libs? It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs? From david.marchand at redhat.com Fri Oct 31 10:17:55 2025 From: david.marchand at redhat.com (David Marchand) Date: Fri, 31 Oct 2025 10:17:55 +0100 Subject: Disable SPDK testing again? In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> Message-ID: On Fri, 31 Oct 2025 at 10:11, Morten Br?rup wrote: > While it is just a warning in the CI dashboard, I don't think we > > should waste resources on this testing. > > Opinions? > > We should ask ourselves why they are doing that. > Is something wrong (or incomplete) with our handling of -Denable_libs? > Are we including unnecessary optional libs? > > It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs? I reached out to some SPDK dev when I was working on enable_libs. I also Cc: one of them on the patches but never got a reply. -- David Marchand From mb at smartsharesystems.com Fri Oct 31 11:02:05 2025 From: mb at smartsharesystems.com (=?UTF-8?B?TW9ydGVuIEJyw7hydXA=?=) Date: Fri, 31 Oct 2025 11:02:05 +0100 Subject: Disable SPDK testing again? In-Reply-To: References: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65520@smartserver.smartshare.dk> > From: David Marchand [mailto:david.marchand at redhat.com] > Sent: Friday, 31 October 2025 10.18 > > On Fri, 31 Oct 2025 at 10:11, Morten Br?rup > wrote: > > While it is just a warning in the CI dashboard, I don't think we > > > should waste resources on this testing. > > > Opinions? > > > > We should ask ourselves why they are doing that. > > Is something wrong (or incomplete) with our handling of - > Denable_libs? > > Are we including unnecessary optional libs? > > > > It seems like they are using -Ddisable_libs, not -Denable_libs. Don't > they know about -Denable_libs? > > I reached out to some SPDK dev when I was working on enable_libs. > I also Cc: one of them on the patches but never got a reply. @Bruce, the SPDK patch [1] was signed off by Tomasz Zawadzki ; maybe you could try reaching out through internal Intel channels and educate him about -Denable_libs. 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? [1]: https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d74e8ff From probb at iol.unh.edu Fri Oct 31 16:13:01 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Fri, 31 Oct 2025 11:13:01 -0400 Subject: Disable SPDK testing again? In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65520@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35F6551F@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35F65520@smartserver.smartshare.dk> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: