On Mon, Mar 18, 2024 at 3:59PM, Patrick Robb wrote:
> On Thu, Mar 7, 2024 at 12:06 PM Adam Hassick <ahassick@iol.unh.edu> wrote:
>>
>> I'm not opposed to having the contexts be a key-value pair argument
>> like the others, however that does break backwards compatibility with
>> our existing syntax. If we don't care very much about backwards
>> compatibility, then we could make this change.
>>
>> Instead of having a boolean and a string parameter for whether to
>> rebase and the branch to rebase on, we could have a single argument
>> specifying a branch. Then, labs rebase on the given branch and then
>> rerun all tests if the "rebase=<branch>" argument is present. This
>> would look like:
>>
>> Recheck-request: rebase=main, iol-sample-apps-testing,
>> iol-unit-amd64-testing, iol-broadcom-Performance
> I agree with this approach because it preserves backward
> compatibility, while still providing us with all the functionality we
> need. We will also be able to accept key value arguments in the future
> if further feature requests come in which require it.
>
>> I don't think the context should be required if the request includes
>> the rebase argument, because we do not want to mix valid and invalid
>> test results as Aaron said.
>> This would be a valid format if contexts are optional:
>>
>> Recheck-request: rebase=main
> Okay, I agree that contexts should not be considered by labs when we
> use rebase - but of course we will still store the contexts (if they
> are submitted) alongside the key value args. In the future there may
> be an application for this.
>
> Zhoumin, does this sound acceptable, or do you think there are any
> flaws? If it works, we will implement the updates and try to upstream
> this week. Thanks!
Thanks for your hard work.
I also agree with this approach. The meaning of the key value
`rebase=main` is sufficient, and loongson lab can support it.
One more thing I want to confirm is whether we should apply the patch
onto the branch commit which existed at the time when that patch was
submitted or onto the latest tip of branch if users request doing
rebase. Users probably request a recheck with `rebase` when the CI lab
chose a wrong branch onto which apply the patch. I worry we may
encounter conflicts when apply the patch onto the latest commit of the
target branch if that branch is just updated before the request.
On Thu, Mar 7, 2024 at 12:06 PM Adam Hassick <ahassick@iol.unh.edu> wrote: > > > I'm not opposed to having the contexts be a key-value pair argument > like the others, however that does break backwards compatibility with > our existing syntax. If we don't care very much about backwards > compatibility, then we could make this change. > > Instead of having a boolean and a string parameter for whether to > rebase and the branch to rebase on, we could have a single argument > specifying a branch. Then, labs rebase on the given branch and then > rerun all tests if the "rebase=<branch>" argument is present. This > would look like: > > Recheck-request: rebase=main, iol-sample-apps-testing, > iol-unit-amd64-testing, iol-broadcom-Performance I agree with this approach because it preserves backward compatibility, while still providing us with all the functionality we need. We will also be able to accept key value arguments in the future if further feature requests come in which require it. > I don't think the context should be required if the request includes > the rebase argument, because we do not want to mix valid and invalid > test results as Aaron said. > This would be a valid format if contexts are optional: > > Recheck-request: rebase=main Okay, I agree that contexts should not be considered by labs when we use rebase - but of course we will still store the contexts (if they are submitted) alongside the key value args. In the future there may be an application for this. Zhoumin, does this sound acceptable, or do you think there are any flaws? If it works, we will implement the updates and try to upstream this week. Thanks!
Hello all, Most DPDK CI meeting attendees appear to be from countries which follow Daylight Savings time. Accordingly, if it is okay with the group I would like to follow our existing practice of adjusting CI meeting times for Daylight Savings, starting with the April 4th meeting. That would mean moving the meeting forward 1 hour, from 14:00 UTC (March 21) to 13:00 UTC (April 4). But please chime in if you have any opinion on this.
Hi Aaron, I'm working on enabling OVS testing in the community lab. Currently, I have a compile test set up which follows the steps defined in the OVS documentation (https://docs.openvswitch.org/en/latest/intro/install/dpdk/) and consumes the shared libraries produced by the DPDK native GCC compile test that we run. This way, we can save some compute resources by not compiling DPDK an additional time. However, this will mean that the OVS compile test will not run if the DPDK compile test fails in any environment, but I think that behavior is acceptable. What do you think? The OVS compile test has passed successfully with DPDK main, which is promising. I'm unsure what the scope of our testing should be as well. Should we run the compile tests on all of our VM/container environments (to get good distro coverage), or just a few? And should we only run periodic testing on main or include LTS, next-* branches? Regards, Adam
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --] Hi Patrick, Yes, it makes sense. Thanks for the note. Please let me know once its sorted out. Thanks Ajit On Thu, Mar 14, 2024 at 7:46 AM Patrick Robb <probb@iol.unh.edu> wrote: > > Hi Ajit, > > One of the tests we run for the BRCM 57414 NIC in the dpdk community > lab is a single core forwarding test in which we try to match line > rate on the NIC, and protect against any performance regressions in > DPDK. We track the MPPS forwarded between interfaces on the DUT, > compare that metric against the most recent "baseline" run, and if the > delta is more than 5% it is a fail. So the idea is if a significant > regression is introduced on a patch, CI testing catches that. > > Right now on one of our ARM systems with brcm57414 this test is having > high variance... more than the 5% threshold in some cases. I think > this may in some way relate to the maintenance we did a few weeks back > - we were seeing like .2% variance before. The expected throughput > seems consistent, but the results have higher variance than normal. > Obviously something is slightly wrong, and the system needs to be > re-tuned a little or something. We can look at it (prefer to do any > maintenance once all RCs are complete), but in the interim I want to > just bump the accepted Delta from 5% to 7%, just to stop the false > fails, but still maintain some coverage. Once we tune the system and > reduce the results variance, we can return to 5%. > > Does this sound fine to you? > > Thanks, > Patrick > > -- > Patrick Robb > > Technical Service Manager > > UNH InterOperability Laboratory > > 21 Madbury Rd, Suite 100, Durham, NH 03824 > > www.iol.unh.edu [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 4218 bytes --]
Hi Ajit, One of the tests we run for the BRCM 57414 NIC in the dpdk community lab is a single core forwarding test in which we try to match line rate on the NIC, and protect against any performance regressions in DPDK. We track the MPPS forwarded between interfaces on the DUT, compare that metric against the most recent "baseline" run, and if the delta is more than 5% it is a fail. So the idea is if a significant regression is introduced on a patch, CI testing catches that. Right now on one of our ARM systems with brcm57414 this test is having high variance... more than the 5% threshold in some cases. I think this may in some way relate to the maintenance we did a few weeks back - we were seeing like .2% variance before. The expected throughput seems consistent, but the results have higher variance than normal. Obviously something is slightly wrong, and the system needs to be re-tuned a little or something. We can look at it (prefer to do any maintenance once all RCs are complete), but in the interim I want to just bump the accepted Delta from 5% to 7%, just to stop the false fails, but still maintain some coverage. Once we tune the system and reduce the results variance, we can return to 5%. Does this sound fine to you? Thanks, Patrick -- Patrick Robb Technical Service Manager UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 www.iol.unh.edu
Hi Honnappa, Since we didn't sync this morning at DTS meeting, I wanted to share the current proposed 24.07 roadmap with you. I think we can asynchronously look it over and approve it. Or, if you want to discuss more in depth, maybe the DPDK CI meeting next week is an appropriate venue. 1) Write ethdev testsuites: Jumboframes: https://git.dpdk.org/tools/dts/tree/test_plans/jumboframes_test_plan.rst Mac Filter: https://git.dpdk.org/tools/dts/tree/test_plans/mac_filter_test_plan.rst Dynamic Queue: https://git.dpdk.org/tools/dts/tree/test_plans/dynamic_queue_test_plan.rst 2) Replace XMLRPC server with Scapy interactive shell: https://bugs.dpdk.org/show_bug.cgi?id=1374 3) Configuration schema updates: Extend hugepage configuration options to allow for different sizes: https://bugs.dpdk.org/show_bug.cgi?id=1370 Cut down total configuration options in schema (not all we originally added are needed): https://bugs.dpdk.org/show_bug.cgi?id=1360 Split testbed and test configuration to different files: https://bugs.dpdk.org/show_bug.cgi?id=1344 4)API Docs generation: https://patchwork.dpdk.org/project/dpdk/list/?series=30877 5)Skip test cases based on testbed capabilities: https://patches.dpdk.org/project/dpdk/patch/20240301155416.96960-1-juraj.linkes@pantheon.tech/ Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1351 6)Rename the execution section/stage: Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1355 7)Add support for externally compiled DPDK: Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=136
Ilya Maximets <i.maximets@ovn.org> writes:
> Starting with image version 20240310.1.0, GitHub runners are using
> 32-bit entropy for ASLR:
>
> $ sudo sysctl -a | grep vm.mmap.rnd
> vm.mmap_rnd_bits = 32
> vm.mmap_rnd_compat_bits = 16
>
> This breaks all the asan-enabled builds, because older asan gets
> confused by memory mappings and crashes with segmentation fault.
>
> The issue is fixed in newer releases of llvm:
> https://github.com/llvm/llvm-project/commit/fb77ca05ffb4f8e666878f2f6718a9fb4d686839
> https://reviews.llvm.org/D148280
>
> But these are not available in Ubuntu 22.04 image.
>
> This should be fixed by GitHub, but until new images are available
> reducing ASLR entropy manually to 28 bits to make builds work.
>
> Reported-at: https://github.com/actions/runner-images/issues/9491
> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
We'll probably need something similar in other projects, too... What a
mess.
Sorry, I forgot to send these last week. March 7, 2024 ##################################################################### Attendees 1. Patrick Robb 2. Ali Alnubani 3. Paul Szczepanek 4. David Marchand 5. Aaron Conole ##################################################################### Minutes ===================================================================== General Announcements * IPSEC-MB requirement increase: * Aaron has some questions about whether this new requirement has been properly documented - having a conversation with Ciara to that end on the mailing list currently * Arm did publish an updated tag for this repo - Ciara has some ideas for what may be going wrong and started a conversation on the mailing list * Patrick Robbwill forward this conversation to Paul * Building under OpenSSL is still supported * Server Refresh: * See the mailing list for the most recent ideas, but we will be putting various options in front of GB in the March meeting * Idea is to try to support as many arches as possible (intel x86, amd x86, arm grace-grace) ===================================================================== CI Status --------------------------------------------------------------------- UNH-IOL Community Lab * Hardware Refresh: * NVIDIA CX7: * Without writing out the whole background for the cx7 testing on our NVIDIA DUT, we are being bandwidth capped by the server with this performance testing, but this can be worked around by acquiring a 2nd CX7 NIC for the DUT server. * For on thing, this corresponds to the testing NVIDIA publishes: https://fast.dpdk.org/doc/perf/DPDK_23_07_NVIDIA_NIC_performance_report.pdf * Patrick has asked whether NVIDIA can donate this NIC. We can also go to the DPDK project asking for it, but they have already provided two cx7 to the Community Lab, so it is not ideal. * Over email we have noted that the Broadwell CPU is old and may not be adequate for higher bandwidth testing * QAT 8970 on Amper Server: Has been dry run and is working * Requires a few change in DTS which Patrick can submit once David/Dharmik give approval (basically relates to loading vfio with custom options for certain QAT devices only) * If there are no objections, UNH folks can write up the automation scripts today and get the testing online today or next week. * Test Coverage changes: * OpenSSL driver test has been added to our unit testing jobs * Marvell mvneta build test has been added, per: https://doc.dpdk.org/guides/nics/mvneta.html * Debian 12 has been added to the CI template engine, and we’re running testing from this now * Need to upstream this. * Robin Jarry noted on Slack UNH has been sending out results to test-reports mailing list without setting in-reply-to message-id for the patchseries. Adam has resolved this. * Ferruh also notes that in looking at this he noticed duplicate emails being sent by UNH, which we still need to resolve * Cody at UNH has been making updates to testing on Windows: * Did modify the 2022 build test this week, moving it from the MSVC preview compiler to the MSVC standard compiler (which with v17.9.2 has now caught up to the build features previously only available in the preview version) * Cody is also adding the Clang and Mingw64 compile jobs to the 2022 server (they are only on server 2019 right now) and also is adding DPDK unit test/fast tests to the 2022 server. * David Marchand noticed a bug with the create artifact script: After failing to apply on the recommended branch and trying to fall back on applying to main, it did not checkout to tip of main. Patrick will look. * Bugzilla ticket was creating noting that we need to add 23.11-staging to our CI --------------------------------------------------------------------- Intel Lab * None --------------------------------------------------------------------- Github Actions * Has to double check the ipsec-mb requirement and how we generate abi symbols. Need to check that they are pulling the right version. * In progress in migrating back to the original server this ran on before the server was physically moved to another location * Going to completely re-image/update the server * Posted a series for adding Cirrus-CI to the robot monitoring * Comments are welcome on the mailin list * Need to add a Cirrus YAML config for the DPDK repo --------------------------------------------------------------------- Loongarch Lab * Zhoumin has stated on the mailing list that he can support the email based retest framework * Possible to store commit hash when series as submitted, and recreate those artifacts as needed * Also can support re-apply on tip of branch X * There is an ongoing conversation on CI mailing list for this ===================================================================== DTS Improvements & Test Development 24.07 Roadmap * Ethdev testsuites: * Nicholas: * Jumboframes: https://git.dpdk.org/tools/dts/tree/test_plans/jumboframes_test_plan.rst * Mac Filter: https://git.dpdk.org/tools/dts/tree/test_plans/mac_filter_test_plan.rst * Prince: * Dynamic Queue: https://git.dpdk.org/tools/dts/tree/test_plans/dynamic_queue_test_plan.rst * Need to vet the testsuites. It may be possible to add additional testcases, refactor testcases. We want to flex the same capabilities as the old testsuites, but make improvements where possible. * We should loop in ethdev maintainers and ask for their review on the testcases * David test an email a couple years ago which priority ranked some ethdev capabilities and testsuites, and if we can find this email we should use it. * https://inbox.dpdk.org/ci/CAJFAV8y8-LSh5vniZXR812ckKNa2ELEJVRKRzT53PVu2zO902w@mail.gmail.com/ * Configuration schema updates: * Nicholas: * Working on the Hugepages allocation first, then will do the other config updates (ripping out some unneeded keys from the schema) * Will follow up with the ethdev testsuites * API Docs generation: * Juraj: Needs review from Thomas (the Doxygen integration part), may need to be addressed when Juraj gets back from vacation. * Skip test cases based on testbed capabilities: * Juraj: RFC should be ready before Juraj leaves on vacation. 24.07 shouldn't be a problem. * RFC Patch: https://patches.dpdk.org/project/dpdk/patch/20240301155416.96960-1-juraj.linkes@pantheon.tech/ * The patch requires https://patches.dpdk.org/project/dpdk/list/?series=31329 * Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1351 * Rename the execution section/stage: * Juraj: Juraj will work on this in 24.07 and submit a patch to continue the discussion. The v1 patch will be ready for 24.07, but the discussion/review could push the patch to 24.11. * Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1355 * Add support for externally compiled DPDK: * Juraj: Juraj will start working on this in 24.07. There's a small chance we'll get this in 24.07, but Juraj wants to target this for 24.11. * Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1365 * Jeremy has a bugzilla ticket for refactoring how we handle scapy on the TG (no more XMLRPC server), and will do this in 24.07 * We will finalize at next DTS meeting ===================================================================== Any other business * Next Meeting: March 21, 2024
***** Service Monitoring on 9ab6452f2653 ***** https on dpdkdashboard.iol.unh.edu is OK! Info: HTTP OK: HTTP/1.1 200 OK - 7836 bytes in 0.043 second response time When: 2024-03-11 09:28:27 -0400 Service: https Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=https
***** Service Monitoring on 9ab6452f2653 ***** ping6 on dpdkdashboard.iol.unh.edu is OK! Info: PING OK - Packet loss = 0%, RTA = 0.90 ms When: 2024-03-11 09:26:55 -0400 Service: ping6 Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=ping6
***** Service Monitoring on 9ab6452f2653 ***** ssh on dpdkdashboard.iol.unh.edu is OK! Info: SSH OK - OpenSSH_8.0 (protocol 2.0) When: 2024-03-11 09:26:52 -0400 Service: ssh Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=ssh
***** Service Monitoring on 9ab6452f2653 ***** ping6 on dpdkdashboard.iol.unh.edu is CRITICAL! Info: CRITICAL - Destination Unreachable (2606:4100:3880:1234::104) When: 2024-03-11 09:25:27 -0400 Service: ping6 Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=ping6
***** Service Monitoring on 9ab6452f2653 ***** https on dpdkdashboard.iol.unh.edu is CRITICAL! Info: CRITICAL - Socket timeout after 10 seconds When: 2024-03-11 09:25:27 -0400 Service: https Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=https
***** Service Monitoring on 9ab6452f2653 ***** ssh on dpdkdashboard.iol.unh.edu is CRITICAL! Info: connect to address 132.177.123.104 and port 22: No route to host When: 2024-03-11 09:25:27 -0400 Service: ssh Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=ssh
***** Host Monitoring on 9ab6452f2653 ***** dpdkdashboard.iol.unh.edu is UP! Info: PING OK - Packet loss = 0%, RTA = 1.75 ms When: 2024-03-11 09:25:26 -0400 Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/host/show?host=dpdkdashboard.iol.unh.edu
[-- Attachment #1: Type: text/plain, Size: 529 bytes --] https://bugs.dpdk.org/show_bug.cgi?id=1397 xuemingl@nvidia.com (xuemingl@nvidia.com) changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from xuemingl@nvidia.com (xuemingl@nvidia.com) --- It works now, thanks very much! -- You are receiving this mail because: You are the assignee for the bug. [-- Attachment #2: Type: text/html, Size: 2518 bytes --]
***** Service Monitoring on 9ab6452f2653 ***** ssh on dpdkdashboard.iol.unh.edu is OK! Info: SSH OK - OpenSSH_8.0 (protocol 2.0) When: 2024-03-09 09:12:01 -0500 Service: ssh Host: dpdkdashboard.iol.unh.edu IPv4: 132.177.123.104 IPv6: 2606:4100:3880:1234::104 http://os-monitor.iol.unh.edu/monitoring/service/show?host=dpdkdashboard.iol.unh.edu&service=ssh
On Mon, Mar 4, 2024 at 10:22 AM Aaron Conole <aconole@redhat.com> wrote: > > zhoumin <zhoumin@loongson.cn> writes: > > > On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote: > > > > On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole <aconole@redhat.com> wrote: > > > > Why not something like: > > > > Recheck-request: [attribute-list],[test-list]... > > > > For example, then we can do: > > > > Recheck-request: rebase=[identifier],.... > > > > where identifier is a branch specifier (or the word 'latest')? > > > > I hadn't thought about the option of allowing branch specifiers. Agree that allowing a human correction process for > > the pw_maintainer_cli.py script choosing the wrong branch sounds helpful. > > > > My original idea was offering 2 options (test original artifact, or re-apply on latest). Do we want to support for > > checking out to a specific commit and re-applying there? I figured that would not be worth it (too much of a niche > > case), but your comments are making me reconsider. > > > > I agree with you that allowing developers to correct the target branch is useful. But, the developer should just provide > > the name of branch instead of commit ID, which is more reasonable. Of course, the rebasing option is more important. > > So, I consider we can allow developers to submit a request as following format: > > > > Recheck-request: rebase=True|branch=main|contexts=iol-compile-amd64-testing, iol-broadcom-Performance,... > > > > We can use "|" as the separator, for example. `rebase` and `branch` can be optional and we can use the default values > > if the developer doesn't provide them. The default is not rebasing for `rebase` option. The default is the branch chosen > > by pw_maintainer_cli.py script for `branch` option. The `contexts` option is required. > > Interesting approach. But I don't know about contexts= or something > like that. It means there are two passes through the regex. > > Also, I don't know about contexts either - if the series was requested > to rebase, every lab that can re-test probably should since the results > aren't going to be valid from the old tests. I'm not opposed to having the contexts be a key-value pair argument like the others, however that does break backwards compatibility with our existing syntax. If we don't care very much about backwards compatibility, then we could make this change. Instead of having a boolean and a string parameter for whether to rebase and the branch to rebase on, we could have a single argument specifying a branch. Then, labs rebase on the given branch and then rerun all tests if the "rebase=<branch>" argument is present. This would look like: Recheck-request: rebase=main, iol-sample-apps-testing, iol-unit-amd64-testing, iol-broadcom-Performance Or, using zhoumin's proposed format: Recheck-request: rebase=main|contexts=iol-sample-apps-testing, iol-unit-amd64-testing, iol-broadcom-Performance I don't think the context should be required if the request includes the rebase argument, because we do not want to mix valid and invalid test results as Aaron said. This would be a valid format if contexts are optional: Recheck-request: rebase=main > > Just spit-balling on syntax. > > > > That said, I agree - if a rebase has been requested, all tests need to > > be rerun. Maybe we should consider that the test labels should be added > > with a run number or something? Or we could also include that the run > > is a rerun. That way for labs that don't currently support the recheck > > request framework, we can easily tell that they weren't re-tried. > > > > so re-report with a modified test label? That is good in that it shows the behavior more clearly. But, it also means > > we will not overwrite any fails. So the fail will still be there, and the patchwork patch page will grow a huge table. > > Maybe this is fine. > > > > Re-report with a modified test label may be better. That can tell people more information about the CI testings, such as > > that the retest indeed happened. > > Just back from PTO - actually, I don't think we need to adjust the > label, but rather the description. That would allow the mechanism that > overwrites the existing test to keep the "checks" page tidy, but also > making the retest information clear. WDYT? Yes, if the Community Lab posted new contexts for every retest then the checks page would get quite long. > > Also raises the point of getting more coverage for the retest framework at other labs. I will email Min Zhou > > regarding how he uses the dpdk-ci project for the loongson build jobs and see how well that can integrate with the > > get_reruns.py script. > > That would be great! >
> -----Original Message----- > From: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com> > Sent: Thursday, March 7, 2024 3:32 PM > To: dpdklab@iol.unh.edu; Test Report <test-report@dpdk.org>; ci@dpdk.org; > Thomas Monjalon <thomas@monjalon.net> > Cc: dpdk-test-reports@iol.unh.edu; Jerin Jacob <jerinj@marvell.com> > Subject: RE: [EXTERNAL] |FAILURE| pw138051-138053 [PATCH] [v7,3/3] > config/arm: allow WFE to > > Hi CI team, > > Looks like the failure is unrelated to the patch set. > > https://lab.dpdk.org/results/dashboard/patchsets/29441/ > Summary of Failures: > > 70/112 DPDK:fast-tests / pcapng_autotest FAIL 7.01s (exit > status 255 or signal 127 SIGinvalid) I think, there is report issue too https://mails.dpdk.org/archives/test-report/2024-March/603290.html Says Debian 12 (arm) failure but according to https://lab.dpdk.org/results/dashboard/patchsets/29441/ To Container-Debian-11-x86 dpdk_unit_test failure. > Ok: 101 > Expected Fail: 0 > Fail: 1 > Unexpected Pass: 0 > Skipped: 10 > Timeout: 0 > > Thanks, > Pavan. > > > -----Original Message----- > > From: dpdklab@iol.unh.edu <dpdklab@iol.unh.edu> > > Sent: Wednesday, March 6, 2024 11:32 PM > > To: Test Report <test-report@dpdk.org> > > Cc: dpdk-test-reports@iol.unh.edu; Pavan Nikhilesh Bhagavatula > > <pbhagavatula@marvell.com> > > Subject: [EXTERNAL] |FAILURE| pw138051-138053 [PATCH] [v7,3/3] > > config/arm: allow WFE to > > > > Prioritize security for external emails: Confirm sender and content > > safety before clicking links or opening attachments > > > > ---------------------------------------------------------------------- > > Test-Label: iol-unit-amd64-testing > > Test-Status: FAILURE > > https://urldefense.proofpoint.com/v2/url?u=http- > > 3A__dpdk.org_patch_138053&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r= > > E3SgYMjtKCMVsB-fmvgGV3o- > > g_fjLhk5Pupi9ijohpc&m=dIJFYlA3GlKptLMsH6Ri-SlT527P- > > hiLSOMoODQZsY80J- > > ZAco913KWmYnAVffWp&s=uAZ8azeZoZpDRHwgjKkH24m8SbUFWMqEC0Xc > > zEpvJ90&e= > > > > _Testing issues_ > > > > Submitter: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com> > > Date: Wednesday, March 06 2024 15:49:57 DPDK git baseline: Repo:dpdk > > Branch: master > > CommitID:362b11d129cbd0c262baab748631622c0570c34e > > > > 138051-138053 --> testing fail > > > > Test environment and result as below: > > > > +------------------+----------------+ > > | Environment | dpdk_unit_test | > > +==================+================+ > > | CentOS Stream 8 | PASS | > > +------------------+----------------+ > > | CentOS Stream 9 | PASS | > > +------------------+----------------+ > > | Debian 12 (arm) | FAIL | > > +------------------+----------------+ > > | Fedora 37 | PASS | > > +------------------+----------------+ > > | Fedora 38 | PASS | > > +------------------+----------------+ > > | Ubuntu 22.04 | PASS | > > +------------------+----------------+ > > | RHEL8 | PASS | > > +------------------+----------------+ > > | Debian Bullseye | PASS | > > +------------------+----------------+ > > | openSUSE Leap 15 | PASS | > > +------------------+----------------+ > > | Ubuntu 20.04 | PASS | > > +------------------+----------------+ > > > > ==== 20 line log output for Debian 12 (arm) (dpdk_unit_test): ==== > > Installing symlink pointing to librte_event_opdl.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_opdl.so > > Installing symlink pointing to librte_event_skeleton.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_event_skeleton.so.24 > > Installing symlink pointing to librte_event_skeleton.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_skeleton.s > > o Installing symlink pointing to librte_event_sw.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_sw.so.24 > > Installing symlink pointing to librte_event_sw.so.24 to > > /usr/local/lib/x86_64- linux-gnu/dpdk/pmds-24.1/librte_event_sw.so > > Installing symlink pointing to librte_event_octeontx.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_event_octeontx.so.24 > > Installing symlink pointing to librte_event_octeontx.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_octeontx.s > > o Installing symlink pointing to librte_baseband_acc.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_acc.so. > > 24 Installing symlink pointing to librte_baseband_acc.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_acc.so > > Installing symlink pointing to librte_baseband_fpga_5gnr_fec.so.24.1 > > to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_fpga_5gnr_fec.so.24 > > Installing symlink pointing to librte_baseband_fpga_5gnr_fec.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_fpga_5gnr_fec.so > > Installing symlink pointing to librte_baseband_fpga_lte_fec.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_fpga_lte_fec.so.24 > > Installing symlink pointing to librte_baseband_fpga_lte_fec.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_fpga_lte_fec.so > > Installing symlink pointing to librte_baseband_la12xx.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_la12xx.so.24 > > Installing symlink pointing to librte_baseband_la12xx.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_la12xx. > > so Installing symlink pointing to librte_baseband_null.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_null.so > > .24 Installing symlink pointing to librte_baseband_null.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_null.so > > Installing symlink pointing to librte_baseband_turbo_sw.so.24.1 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_turbo_sw.so.24 > > Installing symlink pointing to librte_baseband_turbo_sw.so.24 to > > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > > 24.1/librte_baseband_turbo_sw.so > > Running custom install script '/bin/sh > > /home-local/jenkins-local/jenkins- > > agent/workspace/Generic-Unit-Test- > > DPDK/dpdk/config/../buildtools/symlink-drivers-solibs.sh > > lib/x86_64-linux- gnu dpdk/pmds-24.1' > > ==== End log output ==== > > > > CentOS Stream 8 > > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > > Compiler: gcc 8.4.1 20200928 > > > > CentOS Stream 9 > > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > > Compiler: gcc 11.3.1 20220421 > > > > Debian 12 (arm) > > Kernel: Container Host Kernel > > Compiler: gcc 11 > > > > Fedora 37 > > Kernel: Depends on container host system > > Compiler: gcc 12.3.1 > > > > Fedora 38 > > Kernel: Depends on container host > > Compiler: gcc 13.1.1 > > > > Ubuntu 22.04 > > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > > Compiler: gcc 11.3.0 > > > > RHEL8 > > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > > Compiler: gcc 8.3.1 20191121 (Red Hat 8.3.1-5) > > > > Debian Bullseye > > Kernel: 5.4.0-122-generic > > Compiler: gcc 10.2.1-6 > > > > openSUSE Leap 15 > > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > > Compiler: gcc 7.5.0 > > > > Ubuntu 20.04 > > Kernel: 5.4.0-153-generic > > Compiler: gcc 9.4.0-1ubuntu1~20.04.1 > > > > To view detailed results, visit: > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__lab.dpdk.org_results_dashboard_patchsets_29441_&d=DwIBAg&c=nKj > > Wec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o- > > g_fjLhk5Pupi9ijohpc&m=dIJFYlA3GlKptLMsH6Ri-SlT527P- > > hiLSOMoODQZsY80J-ZAco913KWmYnAVffWp&s=d7a- > > 0Yr3B99zRAgpaJTlD3XxMVKa-O1R2C3C7D0Ror0&e= > > > > UNH-IOL DPDK Community Lab > > > > To manage your email subscriptions, visit: > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__lab.dpdk.org_results_dashboard_preferences_subscriptions_&d=DwIBA > > g&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o- > > g_fjLhk5Pupi9ijohpc&m=dIJFYlA3GlKptLMsH6Ri-SlT527P- > > hiLSOMoODQZsY80J- > > ZAco913KWmYnAVffWp&s=yD7CcLRWnAai8OXImH38xaWj0CPxP6RteQc5fH > > Wvx2M&e=
Hi CI team, Looks like the failure is unrelated to the patch set. https://lab.dpdk.org/results/dashboard/patchsets/29441/ Summary of Failures: 70/112 DPDK:fast-tests / pcapng_autotest FAIL 7.01s (exit status 255 or signal 127 SIGinvalid) Ok: 101 Expected Fail: 0 Fail: 1 Unexpected Pass: 0 Skipped: 10 Timeout: 0 Thanks, Pavan. > -----Original Message----- > From: dpdklab@iol.unh.edu <dpdklab@iol.unh.edu> > Sent: Wednesday, March 6, 2024 11:32 PM > To: Test Report <test-report@dpdk.org> > Cc: dpdk-test-reports@iol.unh.edu; Pavan Nikhilesh Bhagavatula > <pbhagavatula@marvell.com> > Subject: [EXTERNAL] |FAILURE| pw138051-138053 [PATCH] [v7,3/3] > config/arm: allow WFE to > > Prioritize security for external emails: Confirm sender and content safety > before clicking links or opening attachments > > ---------------------------------------------------------------------- > Test-Label: iol-unit-amd64-testing > Test-Status: FAILURE > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__dpdk.org_patch_138053&d=DwIBAg&c=nKjWec2b6R0mOyPaz7xtfQ&r= > E3SgYMjtKCMVsB-fmvgGV3o- > g_fjLhk5Pupi9ijohpc&m=dIJFYlA3GlKptLMsH6Ri-SlT527P- > hiLSOMoODQZsY80J- > ZAco913KWmYnAVffWp&s=uAZ8azeZoZpDRHwgjKkH24m8SbUFWMqEC0Xc > zEpvJ90&e= > > _Testing issues_ > > Submitter: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com> > Date: Wednesday, March 06 2024 15:49:57 > DPDK git baseline: Repo:dpdk > Branch: master > CommitID:362b11d129cbd0c262baab748631622c0570c34e > > 138051-138053 --> testing fail > > Test environment and result as below: > > +------------------+----------------+ > | Environment | dpdk_unit_test | > +==================+================+ > | CentOS Stream 8 | PASS | > +------------------+----------------+ > | CentOS Stream 9 | PASS | > +------------------+----------------+ > | Debian 12 (arm) | FAIL | > +------------------+----------------+ > | Fedora 37 | PASS | > +------------------+----------------+ > | Fedora 38 | PASS | > +------------------+----------------+ > | Ubuntu 22.04 | PASS | > +------------------+----------------+ > | RHEL8 | PASS | > +------------------+----------------+ > | Debian Bullseye | PASS | > +------------------+----------------+ > | openSUSE Leap 15 | PASS | > +------------------+----------------+ > | Ubuntu 20.04 | PASS | > +------------------+----------------+ > > ==== 20 line log output for Debian 12 (arm) (dpdk_unit_test): ==== > Installing symlink pointing to librte_event_opdl.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_opdl.so > Installing symlink pointing to librte_event_skeleton.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_event_skeleton.so.24 > Installing symlink pointing to librte_event_skeleton.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_skeleton.so > Installing symlink pointing to librte_event_sw.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_sw.so.24 > Installing symlink pointing to librte_event_sw.so.24 to /usr/local/lib/x86_64- > linux-gnu/dpdk/pmds-24.1/librte_event_sw.so > Installing symlink pointing to librte_event_octeontx.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_event_octeontx.so.24 > Installing symlink pointing to librte_event_octeontx.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_event_octeontx.so > Installing symlink pointing to librte_baseband_acc.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_acc.so.24 > Installing symlink pointing to librte_baseband_acc.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_acc.so > Installing symlink pointing to librte_baseband_fpga_5gnr_fec.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_fpga_5gnr_fec.so.24 > Installing symlink pointing to librte_baseband_fpga_5gnr_fec.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_fpga_5gnr_fec.so > Installing symlink pointing to librte_baseband_fpga_lte_fec.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_fpga_lte_fec.so.24 > Installing symlink pointing to librte_baseband_fpga_lte_fec.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_fpga_lte_fec.so > Installing symlink pointing to librte_baseband_la12xx.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_la12xx.so.24 > Installing symlink pointing to librte_baseband_la12xx.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_la12xx.so > Installing symlink pointing to librte_baseband_null.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_null.so.24 > Installing symlink pointing to librte_baseband_null.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.1/librte_baseband_null.so > Installing symlink pointing to librte_baseband_turbo_sw.so.24.1 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_turbo_sw.so.24 > Installing symlink pointing to librte_baseband_turbo_sw.so.24 to > /usr/local/lib/x86_64-linux-gnu/dpdk/pmds- > 24.1/librte_baseband_turbo_sw.so > Running custom install script '/bin/sh /home-local/jenkins-local/jenkins- > agent/workspace/Generic-Unit-Test- > DPDK/dpdk/config/../buildtools/symlink-drivers-solibs.sh lib/x86_64-linux- > gnu dpdk/pmds-24.1' > ==== End log output ==== > > CentOS Stream 8 > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > Compiler: gcc 8.4.1 20200928 > > CentOS Stream 9 > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > Compiler: gcc 11.3.1 20220421 > > Debian 12 (arm) > Kernel: Container Host Kernel > Compiler: gcc 11 > > Fedora 37 > Kernel: Depends on container host system > Compiler: gcc 12.3.1 > > Fedora 38 > Kernel: Depends on container host > Compiler: gcc 13.1.1 > > Ubuntu 22.04 > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > Compiler: gcc 11.3.0 > > RHEL8 > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > Compiler: gcc 8.3.1 20191121 (Red Hat 8.3.1-5) > > Debian Bullseye > Kernel: 5.4.0-122-generic > Compiler: gcc 10.2.1-6 > > openSUSE Leap 15 > Kernel: 4.18.0-240.10.1.el8_3.x86_64 > Compiler: gcc 7.5.0 > > Ubuntu 20.04 > Kernel: 5.4.0-153-generic > Compiler: gcc 9.4.0-1ubuntu1~20.04.1 > > To view detailed results, visit: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__lab.dpdk.org_results_dashboard_patchsets_29441_&d=DwIBAg&c=nKj > Wec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o- > g_fjLhk5Pupi9ijohpc&m=dIJFYlA3GlKptLMsH6Ri-SlT527P- > hiLSOMoODQZsY80J-ZAco913KWmYnAVffWp&s=d7a- > 0Yr3B99zRAgpaJTlD3XxMVKa-O1R2C3C7D0Ror0&e= > > UNH-IOL DPDK Community Lab > > To manage your email subscriptions, visit: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__lab.dpdk.org_results_dashboard_preferences_subscriptions_&d=DwIBA > g&c=nKjWec2b6R0mOyPaz7xtfQ&r=E3SgYMjtKCMVsB-fmvgGV3o- > g_fjLhk5Pupi9ijohpc&m=dIJFYlA3GlKptLMsH6Ri-SlT527P- > hiLSOMoODQZsY80J- > ZAco913KWmYnAVffWp&s=yD7CcLRWnAai8OXImH38xaWj0CPxP6RteQc5fH > Wvx2M&e=
Hello Patrick,
On Thu, Mar 7, 2024 at 6:27 AM Patrick Robb <probb@iol.unh.edu> wrote:
> 1. As Dharmik and David discussed, there are some QAT devices that
> need VFIO denylist=1. To account for this, in cryptodev_common.py
> (which the crypto perf testsuite imports), we need to add:
>
> given the c62x device id is 37c8
>
> if dev_id in ["37c8", "435", "19e2"]:
> test_case.dut.send_expect('modprobe -r vfio_iommu_type1; modprobe
> -r vfio_pci; modprobe -r vfio_virqfd; modprobe -r vfio', '# ', 5)
> test_case.dut.send_expect('modprobe vfio-pci disable_denylist=1
> enable_sriov=1 vfio-pci.ids=8086:37c9', '# ', 5)
> test_case.dut.send_expect('echo "1" | tee
> /sys/module/vfio/parameters/enable_unsafe_noiommu_mode', '# ', 5)
>
> In order to maintain the custom vfio loading Dharmik recommended. The
> latter two dev ids in that list are for DH895XCC and C3XXX, since they
> are also included in
> https://github.com/torvalds/linux/commit/50173329c8cc0c892eaa7a9d0f0692ac39cd7b04
>
> David and Dharmik, I think this is correct, but please chime in if it isn't.
You probably missed one question I had, mixed with my grmbl about
disable_denylist.
"""
However, I don't think the vfio-pci.ids syntax works for passing parameters.
And in any case, why do you need to set this initial list?
Binding devices (using either driverctl or dpdk-devbind.py) to
vfio-pci should be done the "usual" way, or is there some special case
again for QAT?
"""
Re-reading vfio-pci kernel parsing code, the syntax for vfio-pci.ids
seems ok, my bad.
But I am still not clear if there is a need for a special case here.
bind_qat_device() calls test_case.dut.bind_eventdev_port which itself
calls dpdk-devbind to bind the VF to vfio-pci.
So here, on the topic of loading vfio-pci wrt the QAT quirk, you only need:
# modprobe vfio-pci disable_denylist=1 enable_sriov=1
--
David Marchand
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --] You have been invited to a recurring meeting for Data Plane Development Kit (DPDK) DPDK CI Community Testing Meeting Ways to join meeting: 1. Join from PC, Mac, iPad, or Android https://zoom-lfx.platform.linuxfoundation.org/meeting/91865709518?password=df302f34-a942-4d14-a95b-a6c46ae98fae <https://www.google.com/url?q=https://zoom-lfx.platform.linuxfoundation.org/meeting/91865709518?password%3Ddf302f34-a942-4d14-a95b-a6c46ae98fae&sa=D&source=calendar&ust=1710223294394422&usg=AOvVaw1i67NyASo1YC64uU-mAFAD> 2. Join via audio One tap mobile: US: +12532158782,,91865709518# or +13462487799,,91865709518 Or dial: US: +1 253 215 8782 or +1 346 248 7799 or +1 669 900 6833 or +1 301 715 8592 or +1 312 626 6799 or +1 646 374 8656 or 877 369 0926 (Toll Free) or 855 880 1246 (Toll Free) Canada: +1 647 374 4685 or +1 647 558 0588 or +1 778 907 2071 or +1 204 272 7920 or +1 438 809 7799 or +1 587 328 1099 or 855 703 8985 (Toll Free) Meeting ID: 91865709518 Meeting Passcode: 610444 International numbers: https://zoom.us/u/alwnPIaVT <https://www.google.com/url?q=https://zoom.us/u/alwnPIaVT&sa=D&source=calendar&ust=1710223294394422&usg=AOvVaw2i094z1rXfVUxLV9NNCFKs> [-- Attachment #2: Type: text/html, Size: 5422 bytes --]
Hi all, I have run the crypto_perf_cryptodev_perf DTS testsuite for the QAT card on the Ampere server, and have some updates below: On Wed, Feb 28, 2024 at 3:40 PM Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wrote: > > > > > On Feb 28, 2024, at 2:00 PM, Patrick Robb <probb@iol.unh.edu> wrote: > > > > quick update: > > > > I could bind the QAT VFs to vfio-pci after using the module loading options Dharmik mentioned. > > > > First I tested SYM QAT pmd from dpdk test on the VF and got: > > > > + Tests Total : 751 > > + Tests Skipped : 257 > > + Tests Executed : 659 > > + Tests Unsupported: 0 > > + Tests Passed : 494 > > + Tests Failed : 0 > > + ------------------------------------------------------- + > > Test OK > > > > I can try the crypto performance DTS testsuite next. Let me know if you have any thoughts. > Please go ahead and try. We have not worked on the performance, but it is fine to try. First, two tiny change are needed in DTS to make it work: 1. As Dharmik and David discussed, there are some QAT devices that need VFIO denylist=1. To account for this, in cryptodev_common.py (which the crypto perf testsuite imports), we need to add: given the c62x device id is 37c8 if dev_id in ["37c8", "435", "19e2"]: test_case.dut.send_expect('modprobe -r vfio_iommu_type1; modprobe -r vfio_pci; modprobe -r vfio_virqfd; modprobe -r vfio', '# ', 5) test_case.dut.send_expect('modprobe vfio-pci disable_denylist=1 enable_sriov=1 vfio-pci.ids=8086:37c9', '# ', 5) test_case.dut.send_expect('echo "1" | tee /sys/module/vfio/parameters/enable_unsafe_noiommu_mode', '# ', 5) In order to maintain the custom vfio loading Dharmik recommended. The latter two dev ids in that list are for DH895XCC and C3XXX, since they are also included in https://github.com/torvalds/linux/commit/50173329c8cc0c892eaa7a9d0f0692ac39cd7b04 David and Dharmik, I think this is correct, but please chime in if it isn't. 2. For this testsuite we need to add some whitespace stripping on the lscpu output for ARM systems. For some reason on some systems there is no leading whitespace before "Core(s) per socket" in lscpu, but in others (the arm servers we have at the lab) there is. So, as long as this is all fine, I can submit a patch to DTS for these items. And from there we can run the testsuite and all QAT testcases are passing. It will give some results like: PerfTestsCryptodev: Test Case test_qat_zuc Begin dut.arm-ampere-dut.dpdklab.iol.unh.edu: lscpu dut.arm-ampere-dut.dpdklab.iol.unh.edu: x86_64-native-linux-gcc/app/dpdk-test-crypto-perf -l 9,10 -a 0000:03:01.0 --socket-mem 2048,0 -n 6 -- --ptest throughput --silent --total- CRYPTODEV: Initialisation parameters - name: 0000:03:01.0_qat_sym,socket id: 0, max queue pairs: 0 Allocated pool "sess_mp_0" on socket 0 lcore id Buf Size Burst Size Enqueued Dequeued Failed Enq Failed Deq MOps Gbps Cycles/Buf 10 64 32 30000000 30000000 39393954 33424660 5.5361 2.8345 4.52 10 128 32 30000000 30000000 40170307 34256181 5.4867 5.6184 4.56 10 256 32 30000000 30000000 42119414 36231215 5.3883 11.0352 4.64 10 512 32 30000000 30000000 44557481 38555569 5.2235 21.3955 4.79 10 1024 32 30000000 30000000 55097817 48193496 4.6161 37.8149 5.42 10 2048 32 30000000 30000000 126698128 118908347 3.0483 49.9439 8.20 I will let you folks who are working on this to assess the performance metrics. I assume this is useful, and if/when we bring this to CI, all these results will be stored as artifacts and viewable for any new series which come in. Happy to discuss further tomorrow at the CI meeting. If there are no issues here, I think we can write up the jenkins scripts pretty quickly and get this online tomorrow or early next week.
On Wed, Mar 6, 2024 at 5:00 AM David Marchand <david.marchand@redhat.com> wrote: > > On Tue, Feb 27, 2024 at 8:22 PM Tyler Retzlaff > <roretzla@linux.microsoft.com> wrote: > > > > Enable build of eal & ring library when building with MSVC. > > > > This series depends on 2 other series that seem to be near being > > accepted for merge. > > > > https://patches.dpdk.org/project/dpdk/list/?series=31229 > > https://patches.dpdk.org/project/dpdk/list/?series=31230 > > > > Since the rc2 deadline is soon this series is being submitted now > > to solicit feedback. The CI is expected to fail without the above > > series being merged. > > > > Series applied, thanks Tyler. > > Btw, I noticed a failure in UNH for MSVC, but it is not reported as > such in patchwork. > https://lab.dpdk.org/results/dashboard/patchsets/29302/ > https://patchwork.dpdk.org/project/dpdk/patch/1709061720-4843-3-git-send-email-roretzla@linux.microsoft.com/ > > Is there something to change in how UNH reports for the MSVC job? Hi David, There was a discussion about this on Slack in the infra-issues space. You can see the correct test report here: https://inbox.dpdk.org/test-report/65deb584.d40a0220.71354.9933SMTPIN_ADDED_MISSING@mx.google.com/ Which at the time of the discussion was the latest update for the iol-compile-amd64-testing context sent to patchwork. So this appears to be an anomaly. > > > -- > David Marchand >