From zhoumin at loongson.cn Fri Aug 1 03:27:38 2025 From: zhoumin at loongson.cn (zhoumin) Date: Fri, 1 Aug 2025 09:27:38 +0800 Subject: Email based retests for the Loongarch lab In-Reply-To: References: <24d143d3-4739-457d-bf15-c6224ca21bb0@loongson.cn> <123907a4-bfa2-180d-7abd-fe4c498c5381@loongson.cn> <404eaac9-72da-ffba-3d59-eb2617df03b8@loongson.cn> Message-ID: <47f559d8-7268-9f85-1024-36468c9cef4e@loongson.cn> Hi Patrick Robb, On 2025/7/25 10:24PM, Patrick Robb wrote: > > > On Thu, Jul 17, 2025 at 8:50?AM zhoumin > wrote: > > Hi Patrick Robb, > > On 2025/7/9 8:49AM, Patrick Robb wrote: >> Hi Zhoumin, >> >> Aaron did approve the get_reruns.py patch for the rebase arg and >> merge it to dpdk-ci. So, you are good to pull that into your >> dpdk-ci fork. >> > Thanks for your contributions. I have used this script to support > the retest with rebase arg in Loongson lab. >> On Tue, Jun 17, 2025 at 12:16?AM zhoumin > > wrote: >> >>> Maybe you can apply it, give it a run and add a tested by >>> tag to the patch if it is working for you? >> Yes, I have tested it and it is working for me. This patch >> has a little changes in the inputs and outputs to >> get_reruns.py, and I need to make corresponding changes to >> our current implementation of retest. >>> >> Okay, thanks. When you get the free time to implement these >> change please ping me so I know we are ready for any next steps >> (like updating the labs recheck support status on the DPDK website). > We support the rebase arg now when request to retest. But there > maybe a little difference between Loongson lab and other labs. We > recheck the patches on the latest HEAD of the branch specified by > rebase arg if has or selected by pw_maintainers_cli.py script. I > want to know if there will be any problems with this behaviour? Is > it acceptable? > > > The behavior you describe is correct - when the rebase argument is > used, the patch should be applied to HEAD of the branch specified by > the rebase arg. > > However, I do believe there is a discrepancy in our labs behavior when > it comes to retests which are submitted without the rebase argument. > In this case, UNH lab, AWS, and GitHub are running retests on the > original patch artifacts without re-applying to the current HEAD at > the time of the retest. On the other hand, I believe Loongson does > re-apply to HEAD even when the rebase argument is not specified. I > think in an ideal world our behavior would be uniform across the labs. > What that would require in this case is either: > > 1. Loongson changes to retesting without re-apply on HEAD when no > rebase argument is given (unclear how much work this is) I'm glad to say Loongson lab has changed to retesting without re-apply on HEAD when no rebase argument is given. We recorded the commit ID of the base for the series to test during the first test and use it as the base to retest if no rebase argument is specified. We also ensure that the patch will be applied to HEAD of the branch specified by the rebase argument if it exists. > OR > 2. The other labs change their behavior to just re-apply on HEAD for > every retest, regardless of the rebase argument situation (probably > not a lot of implementation effort, but does reduce user flexibility a > little). > > Sounds like a good topic to discuss at an upcoming CI meeting. :) > > I will send the dpdk-web patch noting that you have added rebase > coverage. Thanks Min Zhou. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Fri Aug 1 15:49:06 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Fri, 1 Aug 2025 09:49:06 -0400 Subject: Email based retests for the Loongarch lab In-Reply-To: <47f559d8-7268-9f85-1024-36468c9cef4e@loongson.cn> References: <24d143d3-4739-457d-bf15-c6224ca21bb0@loongson.cn> <123907a4-bfa2-180d-7abd-fe4c498c5381@loongson.cn> <404eaac9-72da-ffba-3d59-eb2617df03b8@loongson.cn> <47f559d8-7268-9f85-1024-36468c9cef4e@loongson.cn> Message-ID: On Thu, Jul 31, 2025 at 9:29?PM zhoumin wrote: > Hi Patrick Robb, > On 2025/7/25 10:24PM, Patrick Robb wrote: > > > >> > The behavior you describe is correct - when the rebase argument is used, > the patch should be applied to HEAD of the branch specified by the rebase > arg. > > However, I do believe there is a discrepancy in our labs behavior when it > comes to retests which are submitted without the rebase argument. In this > case, UNH lab, AWS, and GitHub are running retests on the original patch > artifacts without re-applying to the current HEAD at the time of the > retest. On the other hand, I believe Loongson does re-apply to HEAD even > when the rebase argument is not specified. I think in an ideal world our > behavior would be uniform across the labs. What that would require in this > case is either: > > 1. Loongson changes to retesting without re-apply on HEAD when no rebase > argument is given (unclear how much work this is) > > I'm glad to say Loongson lab has changed to retesting without re-apply on > HEAD when no rebase argument is given. We recorded the commit ID of the > base for the series to test during the first test and use it as the base to > retest if no rebase argument is specified. We also ensure that the patch > will be applied to HEAD of the branch specified by the rebase argument if > it exists. > Thanks that sounds perfect. :) > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Aug 12 17:59:59 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Tue, 12 Aug 2025 11:59:59 -0400 Subject: DTS WG Meeting Minutes - July 31, 2025 Message-ID: #################################################################### July 31, 2025 Attendees * Patrick Robb * Luca Vizzarro * Paul Szczepanek * Andrew Bailey #################################################################### Minutes ===================================================================== General Discussion * RFC deadline for 25.11 development is August 31. ===================================================================== Patch discussions * RSS: * Updated and rebased. Ivan?s comments have been addressed. * Patrick Robband Andrew Baileyto review this and test it on lab devices (must include mellanox) * dts: add file management * Patrick Robbto review * Provides abstraction which defines a file on TG, SUT, or DTS engine system * There are some stylistic differences between how testsuite docstrings are written * Currently, the only ?rule? is that testsuite developers write ?steps? and ?verify? section * Steps and Verify should also have an empty line included between them * Otherwise, there are various discrepancies (example, ordered vs unordered list for providing ?steps?) and we need to provide more comprehensive rules to bring the testsuite docstrings in alignment * Also some missing ?Attributes? or ?Returns? sections for various class and method docstrings * There is major duplication between module, class, and method docstrings in each testsuite. * Module docstring should be a few sentences briefly identifying the testsuite and the DPDK functionality validated in the testsuite * Testsuite class can just be a stock phrase to satisfy the linter, like ?testsuite class? * Testcase docstrings contain the actual details * Thomas Wilks is looking through testsuites and looking for problems with code style. We should provide a code style guide going forward. * Example: Some functions which return None have no typehinted return, when technically they should return None like ? -> None ? * Testcase naming convention * The old requirement of prefixing testcases with ?test_? is still present in some testcases. Although it?s not a ?problem? for testcases to be named in this way, we should stop doing this going forward and do a 1 time re-naming of all the existing testcases that are named in this way. * Docs builds: * We have some private methods which are not actually made private (they are not prefixed with an underscore), so these methods are showing up in the testsuite docs unnecessarily. * Patrick Robb and luca.vizzarro at arm.comreviewed change requested patches * Confirmed all of those patches are tracked * It may be better to not use the change requested status at all. Just provide comments on series, and let the submitter change the series to ?superseded? when they send a new version. ===================================================================== Bugzilla discussions * Reviewed bugzilla tickets: * https://bugs.dpdk.org/buglist.cgi?quicksearch=component%3Adts&list_id=9444 ===================================================================== Any other business * Andrew at UNH is looking at TG driver binding, which was previously removed from DTS. * Intel CI Docs build had a failure for some DTS docs on a patch applied to next-dts * Need to remove the autodoc pydantic dependency from the standard docs build, which Luca is going to do * Next meeting is Aug 14, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Aug 12 18:33:37 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Tue, 12 Aug 2025 12:33:37 -0400 Subject: Community CI Meeting Minutes - August 7, 2025 Message-ID: Apologies for the delay in sending these notes out. ##################################################################### August 7, 2025 Attendees 1. Patrick Robb 2. Luca Vizzarro 3. Dean Marx 4. Aaron Conole ##################################################################### Minutes ===================================================================== General Announcements * Test rechecks: * DPDK.org patch recheck lab support list has been updated: https://patchwork.dpdk.org/project/web/patch/20250725163057.1059638-1-probb at iol.unh.edu/ * DTS 25.11 Roadmap: https://inbox.dpdk.org/dev/CAJvnSUB2scYCkV4BKFyxHVpPLFmhLYVb20tV0LFDeUHLWfVW+Q at mail.gmail.com/ * Luca has been added as a DTS maintainer, taking Paul?s place ===================================================================== CI Status --------------------------------------------------------------------- AWS Lab * None UNH-IOL Community Lab * The Community Lab will have downtime for a few hours on Tuesday August 12, for system upgrades * Pw-ci: Aaron visited the lab last week and was curious about whether the Community Lab can leverage the pw-ci project, which handles patch polling, patch apply, etc. * UNH guys to look at standing this up side by side with our existing backend to evaluate its usefulness * https://github.com/ovsrobot/pw-ci * Had an infra failure on the ARM Grace server this week, and put in reruns from August 4 - August 6 to correct this. * Has been stable otherwise. --------------------------------------------------------------------- Intel Lab * There were some build failures from Intel CI from the docs build for DTS, which should be fixed with this patch which removes autodoc_pydantic from the build: https://patchwork.dpdk.org/project/dpdk/patch/20250801114547.1128950-1-luca.vizzarro at arm.com/ * Nothing otherwise --------------------------------------------------------------------- Github Actions Robot * Started integration of pull request for Sourcery AI analysis. * This is inadvertently causing testing to run 2x because the extra PR for Sourcery is being picked up by testing * Will have to decide which repo for the pull requests to live in, but it can either be the DPDK repo or ovsrobot repo * Will publish the pull request link in the checkpatch email, so people can click it and look at the AI bot?s comments * If the bot feedback/comments prove useful, then we can look at setting up a system for sending the bot comments as mails on the mailing list. --------------------------------------------------------------------- Loongson Lab * None ===================================================================== DTS Improvements & Test Development * Andrew is adding missing type hints to function args and return types: https://patchwork.dpdk.org/project/dpdk/patch/20250806162900.273571-1-abailey at iol.unh.edu/ * No new comments * QinQ: https://patchwork.dpdk.org/project/dpdk/list/?series=35734 * Dean Marxadd a ticket for trackin vlan_tci and vlan_tci_outer as a later patchseries * Bruce has produced the following table: VLAN Stripping Behavior Table ============================= Input Pkt Tags | VLAN Strip | QinQ Strip | VLAN+QinQ Strip ---------------------|-------------------|----------------------|---------------------------------- 0x8100 | Tag in vlan_tci | -- | Tag in vlan_tci ---------------------|-------------------|----------------------|---------------------------------- 0x88a8 | -- | Tag in vlan_tci_outer| Tag in vlan_tci_outer ---------------------|-------------------|----------------------|---------------------------------- 0x9100 | -- | -- | -- ---------------------|-------------------|----------------------|---------------------------------- | | | ---------------------|-------------------|----------------------|---------------------------------- 0x8100 0x8100 | Tag in vlan_tci | -- | Tag in vlan_tci ---------------------|-------------------|----------------------|---------------------------------- 0x8100 0x88a8 | Tag in vlan_tci | -- | Tag in vlan_tci ---------------------|-------------------|----------------------|---------------------------------- 0x8100 0x9100 | Tag in vlan_tci | -- | Tag in vlan_tci ---------------------|-------------------|----------------------|---------------------------------- 0x88a8 0x8100 | -- | Tag in vlan_tci_outer| Tag in vlan_tci_outer & | | | tag in vlan_tci ---------------------|-------------------|----------------------|---------------------------------- 0x88a8 0x88a8 | -- | Tag in vlan_tci_outer| Tag in vlan_tci_outer ---------------------|-------------------|----------------------|---------------------------------- 0x88a8 0x9100 | -- | Tag in vlan_tci_outer| Tag in vlan_tci_outer ---------------------|-------------------|----------------------|---------------------------------- 0x9100 [any] | -- | -- | -- ---------------------|-------------------|----------------------|---------------------------------- * VM Virtio Testing: * For the proof of concept, we are setting a PvP (physical virtual physical) single VM PoC where both physical functions are leveraged by virtio devices on the VM. * Add file management: https://patchwork.dpdk.org/project/dpdk/list/?series=35807 * Patrick to provide a review today. * RSS Testsuite: https://patchwork.dpdk.org/project/dpdk/list/?series=35836 * Do we need to run this on any particular hardware? * Has been tested on E810 and ConnectX6 * UNH guys can try with Broadcom * Otherwise, Patrick can provide a review. * Forwarding Performance Test: * v3 coming in the next few days * Testcase Docstring Example: https://patchwork.dpdk.org/project/dpdk/patch/20250722171957.200698-1-dmarx at iol.unh.edu/ * Dean Marx to switch the ?steps? to be an unordered list, which will render better in the docs ===================================================================== Any other business * Next Meeting August 21 at the same time -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Thu Aug 14 23:38:04 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 14 Aug 2025 17:38:04 -0400 Subject: DTS WG Meeting Minutes - August 14, 2025 Message-ID: ##################################################################### August 14, 2025 Attendees * Patrick Robb * Luca Vizzarro * Paul Szczepanek * Andrew Bailey * Manit Mahajan * Dean Marx ##################################################################### Minutes ===================================================================== General Discussion * RFC deadline for 25.11 development is August 31. ===================================================================== Patch discussions * DPDKRuntimeEnvironment: * Currently various methods in DPDKRuntimeEnvironment basically have a switch for ?SUT? or ?TG? in various methods, though the DPDKRuntimeEnvironment is only ever instantiated for the TG Node. * So, proposal is to introduce an abstract class for DPDKRuntimeEnvironment, with TG and SUT specific implementations of this abstract class * The main practical reason why we want to be able to instantiate a variant of DPDKRuntimeEnvironment on the TG is in order to call _prepare_devbind_script() so that the TG ports will bind to the correct driver. * Should we move the devbind responsibility to the topology class * Could remove devbind_script_path from linux session * and copy devbind to TG and SUT in the same way, meaning there is one solution now for both nodes * Add File Management: * Desired testlogs output dir structure * Testsuite logs and Testcase logs only include state information * RSS: * Patrick Robband Andrew Baileyto review this and test it on lab devices * Rxtx_offload testsuite: * Morten has drafted a required update to the testplan for mbuf fast free. Patrick will send a new version in new DTS. https://bugs.dpdk.org/show_bug.cgi?id=1769 * DTS API: * In progress * All of the files which are to be exposed to the testsuite surface will be moved to a new ?API? folder, and dts internals which should not be imported to the testsuite will be located elsewhere. * Splitting out some files, for instance for capabilities which users will decorate their testsuites/cases with, the enums for those capabilities are moved to the API dir, though the associated capability code will remain outside of the API dir. * Dean?s checksum testsuite doc updates were merged ===================================================================== Bugzilla discussions * Review bugzilla tickets: * https://bugs.dpdk.org/buglist.cgi?quicksearch=component%3Adts&list_id=9444 ===================================================================== Any other business * VM setup - Virtio: * Investigating different virtio workloads, topologies, and methods of delivering a DPDK ready VM(s) to DTS * Next meeting is Aug 28, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Mon Aug 18 17:34:16 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 18 Aug 2025 11:34:16 -0400 Subject: AWS EC2 ENA instance for a new DTS branch? Message-ID: Hi Shai, I'm thinking about how we can get the DPDK DTS group broadly, and the students at UNH, to start staging DTS for running in a cloud environment (like AWS) during this release cycle, so that we can start running some of the E2E testing DTS provides in this setting. I believe we will have time for this during the 25.11 development period as our "normal" roadmap items are progressing well. Is there a way that you would/will be able to make an AWS EC2 instance with ENA adapter(s) available to the DTS group so that we can begin to work on some testpmd DPDK workloads / make a DTS branch for running DTS in this environment? It seems like getting onto an EC2 instance and experimenting there would be a logical first step. If providing such an instance is problematic or time consuming to you for any technical or bureaucratic reason, then I will ask internally in my lab if I can have a small spend authorization for an AWS account and proceed in that way. Let me know what your thoughts are! Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Aug 19 20:50:47 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Tue, 19 Aug 2025 14:50:47 -0400 Subject: meson error on ARM Grace server 23.11/22.11 In-Reply-To: References: Message-ID: I see Luca just sent a new version of 22.11 which includes the Grace build patch, so this build "issue" should now be resolved for his tree. I hope we will see the same patch reach 23.11 soon. :) Thanks for doing this Doug and Luca. On Tue, May 20, 2025 at 1:15?PM Patrick Robb wrote: > Hi Doug, > > Without overburdening you with details, at the CI lab we have some tests > which run with werror=true (treat warnings as errors) and some which run > without it. The tests which I'm currently trying to extend to LTS for Grace > do not have this flag included, i.e. they are tolerant to warnings. So, we > should be good to proceed with your patch. > > Although no warnings on 22.11 and 23.11 would open us up to adding > werror=true build tests directly on Grace in the future, there isn't an ask > for this right now and I don't think we will need to support it. So, again > I think we can proceed with your patch as is. > > Thanks for handling this. > > On Tue, May 20, 2025 at 1:00?PM Doug Foster wrote: > >> Hi Patrick, >> >> While building 22.11 and 23.11 with GCC 13.3, I noticed compiler warnings >> related to memcpy usage, specifically involving __builtin___memcpy_chk >> failures. >> Would these warnings be a concern for CI test runs, or are they generally >> tolerated? >> >> From: Doug Foster >> Sent: Friday, May 16, 2025 12:16 AM >> To: Patrick Robb ; Wathsala Wathawana Vithanage < >> wathsala.vithanage at arm.com> >> Cc: ci at dpdk.org; dev ; Honnappa Nagarahalli < >> Honnappa.Nagarahalli at arm.com>; stable at dpdk.org; nd >> Subject: RE: meson error on ARM Grace server 23.11/22.11 >> >> Hi Patrick, >> >> I will produce the patches with necessary changes to build on Grace for >> 22.11 and 23.11. >> >> From: Patrick Robb >> Sent: Thursday, May 15, 2025 3:59 PM >> To: Wathsala Wathawana Vithanage >> Cc: mailto:ci at dpdk.org; dev ; Honnappa Nagarahalli >> ; mailto:stable at dpdk.org; Doug >> Foster ; nd >> Subject: Re: meson error on ARM Grace server 23.11/22.11 >> >> Thanks Wathsala, >> >> How can we help on the UNH side? Do you want us to produce the 22.11 and >> 23.11 diffs/patches, which would be based on d007038, with some >> modifications based on what you had said to Doug? >> >> I'm not sure what the process looks like exactly for providing backports >> to LTS maintainers. >> >> On Tue, Apr 29, 2025 at 12:00?PM Wathsala Wathawana Vithanage > wathsala.vithanage at arm.com> wrote: >> > Hi, >> > >> > At the DPDK Community Lab we have been running CI tests with a new ARM >> > Grace server for the past couple of months on main and next-* branches. >> I am >> > trying to add LTS runs now, and ran into a snag with 23.11 and 22.11 >> for this >> > system. Stable maintainers I'm not sure whether this should be >> addressed or not >> > for hardware which is new and didn't exist when 22.11 and 23.11 were >> > released... but I figured I'd make the tickets and find out. I attached >> the meson >> > logs to the tickets and if for whatever reason you guys want to remote >> into this >> > machine, I'm happy to setup the VPN and SSH access. >> > >> > 22.11: https://bugs.dpdk.org/show_bug.cgi?id=1703 >> > 23.11: https://bugs.dpdk.org/show_bug.cgi?id=1702 >> >> +doug >> >> neoverse-v2 is supported in the GCC 13.3 used for this build although >> -mtune/-mcpu >> for grace is not available in that version. >> Adding neoverse-v2 and soc_grace with crypto extension should bring these >> releases >> on par with latest. >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Aug 19 23:48:28 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Tue, 19 Aug 2025 17:48:28 -0400 Subject: Virtio testing goals for DTS Message-ID: Hi Aaron or Maxime, I want to get your perspective on our testing goals for virtio in DTS if you are willing. Dean, who works on DTS, has been running various PVP and PVVP virtio workloads on one of the SUT servers at UNH, as well as some single VM and double VM (with inter VM DPDK forwarding) virtio workloads just on his laptop, so that we can start to get an idea of how we can start validating DPDK virtio. We are aware that there is likely a need/desire for us to setup some vhost-user + virtio testsuites, i.e. there is a tester (traffic gen) server paired up against a SUT server, the SUT server sets up vhost-user device(s), creates a VM(s), and creates a virtio-net-pci device which is connected to the vhost socket from the host, and then we start testpmd in the VM using the virtio-net-pci device(s). Then we send traffic from the TG and assess the DPDK behavior inside the virtio VM. Or, we can run the testpmd inside the VM frontend in tx_only mode and transmit traffic to the backend vhost testpmd. In any case, these are vhost testplan specific details which don't really pertain to my real question which is below. The question I have for you is do you think there would be any benefit to producing testcases that validating DPDK usage of virtio-net-pci devices in a VM, but without involving Vhost, and keeping the entire "test" constrained to a single host. By this I mean, instead of setting up some vhost/testpmd application on the SUT and forwarding packets from physical NIC ports to the vhost vdev (which is then accessed by the VM virtio interfaces), the testcases would involve creating a TAP interface(s) on the SUT, then making a VM and accessing the TAP interfaces via a virtio interface in the VM, and then just starting Scapy on the SUT host and sending traffic at the TAP interfaces, which goes into the VM? This would mean that the test would not involve any physical devices, but it would still be validating DPDK Virtio. One reason why this is attractive is that it would not require particular hardware, I.e. it runs on 1 system and that system could even be your laptop since it only relies on virtual interfaces. David had asked about this possibility at Prague, and I think at that time Maxime piped up to say "and this would also be useful for virtio" or something like that. Anyhow, let me know if you think this makes sense or any other thoughts you may have. If it is a reasonable direction to go in we can start drawing up test plans. I realize this is kind of a wall of text... happy to discuss at the CI meeting on Thursday if that is better. Thanks, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Tue Aug 19 23:49:35 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Tue, 19 Aug 2025 17:49:35 -0400 Subject: Virtio testing goals for DTS In-Reply-To: References: Message-ID: Adding Dean who I forgot to CC. On Tue, Aug 19, 2025 at 5:48?PM Patrick Robb wrote: > Hi Aaron or Maxime, > > I want to get your perspective on our testing goals for virtio in DTS if > you are willing. > > Dean, who works on DTS, has been running various PVP and PVVP virtio > workloads on one of the SUT servers at UNH, as well as some single VM and > double VM (with inter VM DPDK forwarding) virtio workloads just on his > laptop, so that we can start to get an idea of how we can start validating > DPDK virtio. > > We are aware that there is likely a need/desire for us to setup some > vhost-user + virtio testsuites, i.e. there is a tester (traffic gen) server > paired up against a SUT server, the SUT server sets up vhost-user > device(s), creates a VM(s), and creates a virtio-net-pci device which is > connected to the vhost socket from the host, and then we start testpmd in > the VM using the virtio-net-pci device(s). Then we send traffic from the TG > and assess the DPDK behavior inside the virtio VM. Or, we can run the > testpmd inside the VM frontend in tx_only mode and transmit traffic to the > backend vhost testpmd. In any case, these are vhost testplan specific > details which don't really pertain to my real question which is below. > > The question I have for you is do you think there would be any benefit to > producing testcases that validating DPDK usage of virtio-net-pci devices in > a VM, but without involving Vhost, and keeping the entire "test" > constrained to a single host. By this I mean, instead of setting up some > vhost/testpmd application on the SUT and forwarding packets from physical > NIC ports to the vhost vdev (which is then accessed by the VM virtio > interfaces), the testcases would involve creating a TAP interface(s) on the > SUT, then making a VM and accessing the TAP interfaces via a virtio > interface in the VM, and then just starting Scapy on the SUT host and > sending traffic at the TAP interfaces, which goes into the VM? This would > mean that the test would not involve any physical devices, but it would > still be validating DPDK Virtio. One reason why this is attractive is that > it would not require particular hardware, I.e. it runs on 1 system and that > system could even be your laptop since it only relies on virtual > interfaces. David had asked about this possibility at Prague, and I think > at that time Maxime piped up to say "and this would also be useful for > virtio" or something like that. Anyhow, let me know if you think this makes > sense or any other thoughts you may have. If it is a reasonable direction > to go in we can start drawing up test plans. > > I realize this is kind of a wall of text... happy to discuss at the CI > meeting on Thursday if that is better. > > Thanks, > Patrick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Mon Aug 25 19:49:43 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Mon, 25 Aug 2025 13:49:43 -0400 Subject: Community CI Meeting Minutes - August 21, 2025 Message-ID: ##################################################################### August 21, 2025 Attendees 1. Patrick Robb 2. Luca Vizzarro 3. Maxime Coquelin 4. Dean Marx ##################################################################### Minutes ===================================================================== General Announcements * None ===================================================================== CI Status --------------------------------------------------------------------- AWS Lab * How can we access a EC2 ENA instance(s) to test DTS with? * Patrick emailed Shai asking if he can get a credit for us to book something - no word yet * Otherwise, Patrick might be able to just get a little spend auth from the UNH Lab to do this * Otherwise, AWS Lab has been running consistently. --------------------------------------------------------------------- UNH-IOL Community Lab * DTS: From reviewing DTS results from previous weeks, there are 3 testsuites that are occasionally (like 1% of testruns) reporting a false failure due to dropping packets: * Scatter * Vlan * Packet_capture * Checksum offload * UNH team to remove these from CI temporarily and check their packet matching scheme for an implementation issue * Patrick to create tickets for these testsuite * Pw-ci: UNH guys have not deployed an instance of this yet but it?s in the queue. --------------------------------------------------------------------- Intel Lab * None * They had a failure for the mbuf_fast_free tx_offload testcase in legacy DTS. Morten and the intel lab team had a back and forth. Morten has now rewritten the testplan for mbuf_fast_free. --------------------------------------------------------------------- Github Actions Robot * None --------------------------------------------------------------------- Loongson Lab * None ===================================================================== DTS Improvements & Test Development * Virtio VM testing: * One path is a vhost + Virtio type scenario where we are sending packets between physical systems * It may be a good idea to have a test not involving physical NICs, would make it easier to test for contributors broadly. * Vhost kernel is an accel implementation for TAP interfaces * Another option to simplify is to have vhost kernel for providing TAP interface, and connecting to virtio_user PMD, don?t create a VM. Will not be testing the pci layer, rather the virtio-user PMD directly connected to the TAP interface, but the datapath will be the same. * Does not require having a VM to be installed, which reduces the setup burden both for DTS framework and for the ?user? in terms of system dependencies * Doc: https://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html * Our first virtio testsuite will use this method * Doc: https://doc.dpdk.org/guides/howto/virtio_user_for_container_networking.html * Could test vduse - create vhost-vdpa devices * Can connect to QEMU like you can connect vhost-user devices * Or can connect to virtio_user PMD * But, this is lower priority * If DTS team has questions, we can reach out to Maxime on Slack. * Vhost virtio test without a VM would be using virtio vdevs for testpmd on the host * Enable driver binding on the TG: * Patrick thinks the implementation looks good. He ran a testrun from this patch with the TG driver unbound, and it did correctly bind, but then the link was down on the TG interface so the sniffer could not be created. * Patrick to check where the ip link set dev up command is run in the port setup, and see if that is missing now, or if it is being called too early, or something else. * Andrew is adding the mbuf_fast_free testcase to new DTS based on Morten?s testplan. * artifacts: https://patchwork.dpdk.org/project/dpdk/list/?series=35807 * Will submit a new version in the next few weeks * Original intention was to have a global log and a testsuite specific log. * There is no intention to have testcase specific log files (as is the case with the V1) * QinQ strip: Next step is to test on Broadcom and share back to Ajit and maybe Morten/Bruce if those results are meaningful * RSS: Patrick needs to do a review on this ASAP * This is top priority for the UNH guys * Change default topology to 1 link: * Patrick to merge * https://patchwork.dpdk.org/project/dpdk/list/?series=35971 * Docs updates: * Fix missing type hints (Andrew is working on this) * Rewrite steps and verify sections, and add a new script under dts-check-format which validates conformance to this test/verify docstring for each testcase (Dean has submitted this) * The python check script that Dean is proposing to add to the DPDK devtools dir needs to be prefixed with dts-* in the name so that it is clear it is to be used for DTS * Reduce duplication between module docstrings, class docstrings, and function docstrings. Thomas Wilks will work on this one. * Remove test_ prefix from testcases: https://patchwork.dpdk.org/project/dpdk/patch/20250820151215.47742-1-dmarx at iol.unh.edu/ * Patrick to merge this * Adding missing type hints: https://patchwork.dpdk.org/project/dpdk/patch/20250820151850.484576-1-abailey at iol.unh.edu/ * Patrick to give a final review and merge it * API dir: * Goal is that tests only import from api/* and nothing from framework/* ===================================================================== Any other business * Next Meeting is Sep 4, 2025 -------------- next part -------------- An HTML attachment was scrubbed... URL: From probb at iol.unh.edu Thu Aug 28 19:50:16 2025 From: probb at iol.unh.edu (Patrick Robb) Date: Thu, 28 Aug 2025 13:50:16 -0400 Subject: next-crypto rebase on main? Message-ID: Hi Akhil, Would it be simple and harmless for you to rebase next-crypto on main? I see it is a little out of date and on the community lab CI testing side we are seeing some weird behavior for patches which are applied to next-crypto. I think it's nothing though and will go away when your branch is moved forward. If that's an issue in any way please say so. -Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From gakhil at marvell.com Thu Aug 28 20:47:29 2025 From: gakhil at marvell.com (Akhil Goyal) Date: Thu, 28 Aug 2025 18:47:29 +0000 Subject: [EXTERNAL] next-crypto rebase on main? In-Reply-To: References: Message-ID: Hi Patrick, Thanks for notifying. It is rebased now. ZjQcmQRYFpfptBannerEnd Hi Akhil, Would it be simple and harmless for you to rebase next-crypto on main? I see it is a little out of date and on the community lab CI testing side we are seeing some weird behavior for patches which are applied to next-crypto. I think it's nothing though and will go away when your branch is moved forward. If that's an issue in any way please say so. -Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: