On Wed, Jul 16, 2025 at 4:54 PM Dean Marx wrote:
> code.
>
>
> How To Write a Test Suite
> -
>
> -All test suites inherit from ``TestSuite`` defined in
> ``dts/framework/test_suite.py``.
> -There are four types of methods that comprise a test suite:
> +All test suites ar
On Wed, Jul 16, 2025 at 9:57 AM Dean Marx wrote:
>
> +
> +* Document ``__init__()`` separately from the class docstring.
> +* If an abstract method simply implements a superclass definition without
> changes, refer to that superclass in the docstring.
> +* Document instance variables in the class
> Reviewed-by: Patrick Robb
> ---
> doc/guides/tools/dts.rst | 194 ++-
> 1 file changed, 90 insertions(+), 104 deletions(-)
>
> diff --git a/doc/guides/tools/dts.rst b/doc/guides/tools/dts.rst
> index 8ba855c6fc..4da55e00ef 100644
>
On Mon, Jul 14, 2025 at 1:13 PM Dean Marx wrote:
>
> +
> +# Simple Linux Setup
> +
> +1. On your TG and SUT nodes, add a dedicated user. In this example I will
> add a dedicated user for DTS.
>
This is getting away from what I was suggesting. The original version was:
On your TG and SUT nodes,
On Tue, Jul 15, 2025 at 3:47 AM Bruce Richardson
wrote:
>
>
> Thanks. Let me know how the testing otherwise goes. If only Intel NICs are
> supporting QinQ, then it can't be that widely used a feature yet, so we may
> be able to tweak things a bit if it diverges from what is expected.
>
Yeah, the
+c...@dpdk.org
+Manit Mahajan
+Andrew Bailey
Thank you for this we will modify our Clang and MSVC build pipelines at UNH.
Acked-by: Patrick Robb
On Tue, Jul 15, 2025 at 10:14 AM Andre Muezerie <
andre...@linux.microsoft.com> wrote:
> The linker parameters to use with MSVC and Cla
On Mon, Jul 14, 2025 at 4:09 PM Dean Marx wrote:
> On Mon, Jul 14, 2025 at 9:30 AM Bruce Richardson
> wrote:
> >
> > The behaviour of VLAN tag stripping Rx offloads is unclear in DPDK, and
> > not very well documented. Even the documentation that does exist appears
> > contradictory.
> >
> > For
.
> + Example: self.verify(link_up, "Link should be up after configuration.")
>
> -#. **Other methods**
> +Other Methods
>
> - Of course, all test suite code should adhere to coding standards.
> - Only the above methods will be treated specially and any other methods
> may be defined
> - (which should be mostly private methods needed by each particular test
> suite).
> - Any specific features (such as NIC configuration) required by a test
> suite
> - should be implemented in the ``SutNode`` class (and the underlying
> classes that ``SutNode`` uses)
> - and used by the test suite via the ``sut_node`` field.
> + All test suite code should follow the project's coding standards.
> + Only test cases, setup/teardown hooks, and verification methods are
> treated specially by the framework.
> + Additional methods may be defined as needed (ideally private).
> + Any specific features (such as NIC configuration) should be
> implemented in the SutNode class or its supporting classes, and accessed
> using the sut_node field.
>
There's no such class as SutNode anymore.
>
>
> .. _dts_dev_tools:
> --
> 2.49.0
>
>
Also, this series should adjust the poetry section to explain that "poetry
shell" is deprecated now and one must use "poetry run" instead.
Reviewed-by: Patrick Robb
are or software-based.
Not to be a grammar nitpicker but I believe semicolons separate independent
clauses. Maybe just change to:
Node that sends traffic to the SUT, which can be hardware or software-based.
>
>
> 2.49.0
>
>
Reviewed-by: Patrick Robb
On Fri, Jul 11, 2025 at 1:25 PM Dean Marx wrote:
> Remove unnecessary information from README.md,
>
I would call the dropped information "extraneous".
> and add new sections to clarify the purpose/use
> of DTS along with clear setup instructions.
>
Maybe say that the goal of the commit is ref
#
July 9, 2025
Attendees
1. Patrick Robb
2. Manit Mahajan
3. Dean Marx
4. Luca Vizzarro
5. Shai Brandes
6. Aaron Conole
#
Minutes
On Wed, Jul 9, 2025 at 3:57 PM Thomas Monjalon wrote:
> 25/06/2025 06:07, Patrick Robb:
> > Applied to next-dts, thanks Dean.
>
> I'm almost sure it has overriden some doc added recently by Nicholas
> Pratte.
>
Good catch. It removed some sentences explaining usage o
On Tue, Jul 8, 2025 at 6:56 PM Patrick Robb wrote:
> #
> July 3, 2025
> Attendees
> * Patrick Robb
> * Manit Mahajan
> * Dean Marx
>
> ###
#
July 3, 2025
Attendees
* Patrick Robb
* Manit Mahajan
* Dean Marx
#
Minutes
=
General
#
June 25, 2025
Attendees
1. Patrick Robb
2. Manit Mahajan
3. Dean Marx
#
Minutes
=
General
FYI based on conversation with Dean I pushed a fixup adding
the use_virtual_functions: false field to the test_run.example.yaml, so
that users can more easily understand how to enable the VF testruns.
https://git.dpdk.org/next/dpdk-next-dts/commit/?id=934206f3bfc10fb8dcd852479f3683c01a18e352
Series applied to next-dts, thanks.
On Fri, Jul 4, 2025 at 12:25 AM Patrick Robb wrote:
> And FYI VF results for ConnectX-5 virtual functions for a testrun I just
> ran
>
> test_suites: ERROR
> vlan: PASS
> test_vlan_header_insertion: PASS
> test_
Applied to next-dts, thanks.
On Fri, Jul 4, 2025 at 11:30 AM Luca Vizzarro wrote:
> Usage of example DPDK apps should be avoided. Therefore, remove
> the function that allows to build example apps. Moreover,
> provide a dedicated helper function to retrieve the path to a
> DPDK app.
>
> Signed-o
Applied to next-dts, thanks.
On Fri, Jul 4, 2025 at 11:30 AM Luca Vizzarro wrote:
> Add a generic blocking app class to allow a test writer to run any app
> in the background. Make the original BlockingDPDKApp class inherit from
> this one. Implement the new BlockingApp class in the packet_captu
And FYI VF results for ConnectX-5 virtual functions for a testrun I just ran
test_suites: ERROR
vlan: PASS
test_vlan_header_insertion: PASS
test_vlan_no_receipt: PASS
test_vlan_receipt_no_stripping: PASS
test_vlan_receipt_stripping: PASS
rte_flow: FAIL
test_drop_action_ETH:
Reviewed-by: Patrick Robb
Tested-by: Patrick Robb
oftnic(TestSuite):
> """Softnic test suite."""
> diff --git a/dts/tests/TestSuite_uni_pkt.py
> b/dts/tests/TestSuite_uni_pkt.py
> index fdb9c29059..690c5d4fd1 100644
> --- a/dts/tests/TestSuite_uni_pkt.py
> +++ b/dts/tests/TestSuite_uni_pkt.py
> @@ -20,6 +20,7 @@
> from scapy.packet import Packet, Raw
>
> from framework.remote_session.testpmd_shell import (
> +NicCapability,
> RtePTypes,
> SimpleForwardingModes,
> TestPmdShell,
> @@ -258,6 +259,7 @@ def test_nsh_packet_detect(self) -> None:
> with TestPmdShell() as testpmd:
> self.setup_session(testpmd=testpmd, expected_flags=flag_list,
> packet_list=packet_list)
>
> +@requires(NicCapability.PHYSICAL_FUNCTION)
> @func_test
> def test_vxlan_tunnel_packet_detect(self) -> None:
> """Ensure the correct flags are shown in the verbose output when
> sending VXLAN packets.
> --
> 2.49.0
>
>
In principle some of the functions performed in these testsuites should be
possible via VFs.
As a follow up task in 25.11 we should assess this and see if the total
list of VF compatible testsuites can be extended.
Reviewed-by: Patrick Robb
Tested-by: Patrick Robb
you can raise this item at the next DTS meeting for
discussion? It could make sense to support this check for PFs for 25.11.
Anyhow we can discuss.
> def stop(self, verify: bool = True) -> str:
> """Stop packet forwarding.
>
> --
> 2.49.0
>
>
Reviewed-by: Patrick Robb
Tested-by: Patrick Robb
On Wed, Jul 2, 2025 at 12:23 PM Dean Marx wrote:
> Add virtual functions to DTS framework, along with
> a field for specifying VF test runs in the config file.
>
> Signed-off-by: Patrick Robb
> Signed-off-by: Dean Marx
> ---
> dts/framework/config/test_run.py
LGTM, thanks.
As it relates to the TREX patch, yes I will try to refactor towards using
this to handle the TREX foreground server process. I guess the one change I
would need to make is changing the default InteractiveShell timeout from 5
seconds to a larger number (like 20) since TREX can take a
uot;""Retrieve path for a DPDK app."""
> +return self._session.join_remote_path(self.remote_dpdk_build_dir,
> "app", f"dpdk-{app_name}")
> +
> @cached_property
> def remote_dpdk_tree_path(self) -> PurePath:
> """The remote DPDK tree path."""
> --
> 2.43.0
>
>
Otherwise this looks fine for dumpcap and the others /app apps - thanks.
Reviewed-by: Patrick Robb
lass ResultLeaf(BaseModel):
> +"""Class representing a result in the results tree.
>
> -class DtsRunResultDict(TypedDict):
> -"""Represents the `DtsRunResult` results.
> +A leaf node that can contain the results for a
> :class:`~.test_suite.TestSuite`,
> +:class:`.test_suite.TestCase` or a DTS execution step.
>
> Attributes:
> -test_runs: A list of test run results.
> -summary: A summary dictionary containing overall statistics for
> the test runs.
> +result: The actual result.
> +reason: The reason of the result.
> """
>
>From running some testcases that resulted in Error or Fail, I agree adding
this is a big benefit. Providing an example for any others on the mailing
list who are curious:
rte_flow: FAIL
test_drop_action_ETH: PASS
test_drop_action_IP: PASS
test_drop_action_L4: PASS
test_drop_action_VLAN: PASS
test_egress_rules: SKIP
reason: flow rule failed validation.
test_jump_action: PASS
test_modify_actions: FAIL
reason: Packet was never received.
test_priority_attribute: PASS
test_queue_action_ETH: PASS
test_queue_action_IP: PASS
test_queue_action_L4: PASS
test_queue_action_VLAN: PASS
>
>
> --
> 2.43.0
>
>
Looks good, I will apply to next-dts now.
Reviewed-by: Patrick Robb
Tested-by Patrick Robb
Reviewed-by: Patrick Robb
On Fri, Jun 27, 2025 at 11:12 AM Thomas Wilks wrote:
> From: Luca Vizzarro
>
> The test suite name property was previously returning the class name
> instead of the way that test suite are actually named, e.g.
> TestHelloWorld instead of hello_world.
: Nicholas Pratte
Signed-off-by: Patrick Robb
Reviewed-by: Dean Marx
---
dts/configurations/tests_config.example.yaml | 12 +++
dts/framework/test_suite.py | 34 ++--
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/dts/configurations
ed to include
a performance traffic generator in addition to a functional traffic
generator.
Bugzilla ID: 1697
Signed-off-by: Nicholas Pratte
Signed-off-by: Patrick Robb
Reviewed-by: Dean Marx
---
dts/framework/config/test_run.py | 20 +-
dts/framework/context.py
From: Nicholas Pratte
Add an extra parameter to the interactive shell send command
to handle function to allow for a 1 time override of the send
command timeout.
Bugzilla ID: 1697
Signed-off-by: Nicholas Pratte
Signed-off-by: Patrick Robb
Reviewed-by: Dean Marx
---
dts/framework
From: Nicholas Pratte
Rework TG class hierarchy to include performance traffic generators.
As such, methods specific to capturing traffic have been moved to the
CapturingTrafficGenerator subclass.
Bugzilla ID: 1697
Signed-off-by: Nicholas Pratte
Signed-off-by: Patrick Robb
Reviewed-by: Dean
modification to the
settings module.
Bugzilla ID: 1697
Signed-off-by: Nicholas Pratte
Signed-off-by: Patrick Robb
Reviewed-by: Dean Marx
---
dts/{ => configurations}/nodes.example.yaml| 0
dts/{ => configurations}/test_run.example.yaml | 13 +++--
dts/{ => confi
Resolved.
On Fri, Jun 27, 2025 at 10:20 AM Patrick Robb wrote:
>
>
> On Thu, Jun 26, 2025 at 3:56 PM Dean Marx wrote:
>
>> Add an RTE Flow API testing suite, which covers some basic
>> synchronous Flow API rules that should be supported across PMDs.
>> This suite
sending one monolithic series
> would be impossible.
>
> Signed-off-by: Dean Marx
> Reviewed-by: Patrick Robb
> ---
> doc/api/dts/tests.TestSuite_rte_flow.rst | 8 +
> dts/tests/TestSuite_rte_flow.py | 790 +++
> 2 files changed, 798 insertions(
Applied to next-dts, thanks.
On Thu, Jun 26, 2025 at 3:56 PM Dean Marx wrote:
> Add a method for validating flow rules to the testpmd shell class.
> Implement test case skipping for flow rules that do not pass
> validation.
>
> Signed-off-by: Dean Marx
> Reviewed-by: Patrick
cover all in one suite, and sending one monolithic series
> would be impossible.
>
> Signed-off-by: Dean Marx
> Reviewed-by: Patrick Robb
> ---
> doc/api/dts/tests.TestSuite_rte_flow.rst | 8 +
> dts/tests/TestSuite_rte_flow.py | 790 +++
&
get_packet_summaries, to_pascal_case
>
> @@ -411,6 +411,25 @@ def _fail_test_case_verify(self, failure_description:
> str) -> None:
> self._logger.debug(command_res.command)
> raise TestCaseVerifyError(failure_description)
>
> +def verify_skip(self, condition: bool, skip_reason: str) -> None:
>
Maybe rename to "verify_else_skip" so it is more descriptive? Up to you.
>
>
Reviewed-by: Patrick Robb
actions=["queue index 3"],
> +),
> +]
> +expected_queue_list = [1, 2, 3]
> +with TestPmdShell(rx_queues=4, tx_queues=4) as testpmd:
> +testpmd.set_verbose(level=1)
> +for flow, expected_queue in zip(flow_list,
> expected_queue_list):
> +testpmd.flow_create(flow_rule=flow, port_id=0)
> +testpmd.start()
> +self.send_packet_and_capture(test_packet)
> +verbose_output =
> testpmd.extract_verbose_output(testpmd.stop())
> +received = False
> +for testpmd_packet in verbose_output:
> +if testpmd_packet.queue_id == expected_queue:
> +received = True
> +self.verify(received, f"Packet was not received on queue
> {expected_queue}")
> --
> 2.49.0
>
Reviewed-by: Patrick Robb
s 1234"],
> actions=["drop"]),
> +FlowRule(direction="egress", pattern=["udp src is 5000"],
> actions=["drop"]),
> +]
> + # Verify packet reception without flow rule
> +self.send_packet_and_verify(packet=Raw(load="x"),
> should_receive=True)
> +self.runner(
> +verification_method=self.send_packet_and_verify,
> +flows=flow_list,
> +packets=packet_list,
> +should_receive=False,
> +)
>
It looks like for testing these egress rules you are adding the egress flow
rule on port 0, but we are actually egressing on port 1 (if 2 link topology
is enforced as you decorate this testsuite with). So, if my understanding
is correct, then you need to egress on port 1, or on ctx.topology egress
port (same thing).
> --
> 2.49.0
>
>
Remember to include a testsuite rst like
https://git.dpdk.org/dpdk/commit/?id=d23083df08114975987753a887f1d1deed387ce2
Reviewed-by: Patrick Robb
Applied to next-dts, thanks Dean.
Applied to next-dts, thanks Dean.
Yes the windows failure was unrelated to your patch - sorry about the
noise.
Looks like Paul has applied this commit to next-dts.
On Mon, Jun 16, 2025 at 4:23 AM Clemens Famulla-Conrad <
cfamullacon...@suse.com> wrote:
> > Thanks. This needs to pass the linter, see my suggestions below.
>
> Than
On Tue, Jun 17, 2025 at 11:18 AM Luca Vizzarro
wrote:
> Looks good to me. just a small nit:
>
> On 16/06/2025 19:38, Dean Marx wrote:
> > +test_run.ctx.topology.setup()
> > +self.test_run.ctx.topology.configure_ports("sut", "dpdk")
>
> no need to do `self.` here. Outside of this:
ain before the capability check.
Reviewed-by: Patrick Robb
On Mon, Jun 16, 2025 at 8:17 PM Patrick Robb wrote:
> Recheck-request: iol-intel-Functional
>
Recheck-request: iol-intel-Functional
On Thu, Jun 12, 2025 at 4:12 PM Dean Marx wrote:
> Rearrange the topology and DPDK setup/teardown calls during
> test runs to ensure the devbind script is not called
> while the DPDK tmp directory doesn't exist.
>
> Fixes: 4cef16f1f0a4 ("dts: improve port handling")
>
> Signed-off-by: Dean Marx
Good catch David on this system having a partial install of mlx5dev
header/library.
NVIDIA guys, do any of you have a link to the current install procedure or
package? If not I can probably find whatever is correct. Thanks.
Either way we'll update devx on the Windows system Monday - thanks for yo
Recheck-request: iol-compile-amd64-testing
Just sending this recheck request to ensure that our reporting script is
fixed and that it reports a FAIL instead of a WARN. Once that's done, we'll
upgrade the meson version on the system and do another retest.
#
June 12, 2025
Attendees
1. Patrick Robb
2. Paul Szczepanek
3. Aaron Conole
4. Manit Mahajan
5. Dean Marx
#
Minutes
Loongarch is spelled with 2 o's :)
Recheck-request: loongarch-unit-testing
Recheck-request: rebase=main, loongarch-compilation
I don't actually need a compile recheck, I'm submitting this recheck solely
as a means of testing/demonstrating the recheck framework rebase function.
Hi DTS contributors,
I am unable to host the meeting this Thursday. And, like we discussed at
the previous meeting, a couple other regular attendees also have conflicts
this week. I have discussed with Paul and we're going to cancel this
meeting and handle any conversations over email this week.
#
May 29, 2025
Attendees
1. Patrick Robb
2. Paul Szczepanek
3. Aaron Conole
4. Manit Mahajan
#
Minutes
#
May 22, 2025
Attendees
* Patrick Robb
* Luca Vizzarro
* Paul Szczepanek
* Manit Mahajan
* Dean Marx
* Matthew McGovern
#
Minutes
/18 date.
And I see that there is no project filter provided by the /events/
endpoint. https://patchwork.dpdk.org/api/events/
Adam, would you agree the project filter for API requests is pretty low
hanging fruit? Seems like a common sense improvement to me.
On Tue, May 6, 2025 at 3:08 PM Patrick
Steps:
For each port enable flow control for RX and TX individually.
Verify:
The configuration persists after the port is restarted.
"""
> + - Import the ``func_test`` and/or ``perf_test`` decorators from
> ``TestSuite`` and add them above each test case method,
> + e.g., ``@func_test`` followed by ``test_basic_link``
> +
> +- Setup/Teardown Hooks
> + - Suite-level: ``set_up_suite()``, ``tear_down_suite()``
> + - Case-level: ``set_up_test_case()``, ``tear_down_test_case()``
> +
> +- Verification
> + Use ``self.verify(condition, message)`` to record test results.
>
I think the important part of "verify" to explain to people is that you are
setting the testcase assertion condition, not the recording aspect.
> +
> +- Support Methods
> + Helper logic (e.g., traffic handling, config) should be in private
> methods or delegated to ``sut_node``.
>
I realize this is just a rewording that crept in, but this is wrong for a
couple reasons:
1. We no longer import node/sutnode when writing testsuites. Node is purely
framework code now, and is not exposed to testsuites.
2. sut_node (and tg_node) no longer exists.
> +
> +
> +.. _dts_dev_tools:
> +
> +Developer Tools
> +---
> +
> +- ruff
> + - Linter and formatter (replaces flake8, pylint, isort, etc.)
> + - Compatible with Black
> +
> +- mypy
> + - Performs static type checking
> +
> +Run checks using:
> +
> +.. code-block:: console
>
> -These two tools are all used in ``devtools/dts-check-format.sh``,
> -the DTS code check and format script.
> -Refer to the script for usage: ``devtools/dts-check-format.sh -h``.
> + devtools/dts-check-format.sh
>
>
> .. _building_api_docs:
> --
> 2.49.0
>
>
Lots of improvements overall - keep up the good work! A productive Summer
ahead.
Reviewed-by: Patrick Robb
l on your base system. I would leave this
part in, but stick a sentence in at the start saying "usage of vscode
devcontainers is NOT required for developing on DTS and running DTS, but
provide some small quality of life improvements for the developer. If you
want to develop from a devcontainer, see the instructions here" or
somethign like that.
> -### Other
> +## Other
>
> -Searching for '$IDE dev containers' will probably lead you in the right
> direction.
> +Searching for '$IDE dev containers' will probably lead you in the right
> direction.
> \ No newline at end of file
> --
> 2.49.0
>
>
Reviewed-by: Patrick Robb
#x27;s
unrelated to patch 1 and 2, but it's not functionally relevant since there
is no such thing as a series in git, so you don't need to resubmit. Keep in
mind for future series though that they should be logically grouped.
Reviewed-by: Patrick Robb
>
> def extract_noise_information(
> self, verbose_out: list[TestPmdVerbosePacket]
> --
> 2.49.0
>
>
res.
> 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.vithan...@arm.com>
> Cc: c...@dpdk.org; dev ;
#
May 15, 2025
Attendees
1. Patrick Robb
2. Paul Szczepanek
3. Luca Vizzarro
4. Manit Mahajan
5. Aaron Conole
#
Minutes
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.
Reviewed-by: Patrick Robb
transmission rates.
>
>
>
Obviously the testsuite is a placeholder to demonstrate the TG usage, as
you say, which is all good.
Reviewed-by: Patrick Robb
{self._tg_config.config} -i
> +"""
>
I know this was just a work in progress for RFC with some hardcoding, but
you already have tg_config.remote_path, right? So, the leading hardcoded cd
does not do anything, and even if you had to cd there you could use the
tg_config.remote_path?
Reviewed-by: Patrick Robb
elongs in the testsuite?
> +) -> PerformanceTrafficStats:
> +"""Send packet traffic and acquire associated statistics."""
> +return self._calculate_traffic_stats(packet, duration,
> self._generate_traffic)
> +
> +def setup(self, ports):
> +"""Preliminary port setup prior to TG execution."""
> +for port in self._tg_node.ports:
> +self._tg_node.main_session.configure_port_mtu(2000, port)
>
Okay just checking... so if we do not do this, even after binding the port
to vfio-pci we cannot send traffic up to 2000 bytes?
Reviewed-by: Patrick Robb
Okay, I'll make a ticket for us to look at this again and raise it at the
CI meeting this morning. Thanks for the heads up.
On Thu, May 15, 2025 at 8:59 AM David Marchand
wrote:
> On Tue, Apr 2, 2024 at 2:46 AM Stephen Hemminger
> wrote:
> >
> > On Mon, 1 Apr 2024 18:
On Thu, May 15, 2025 at 1:40 PM David Marchand
wrote:
>
>
> Retests show the same error, so I think we are hitting the issue fixed
> with dbcd72f3fba0.
>
> Bumping the minimal version to 0.57.2 seems fine.
> I looked and can't find a distrib that ships meson 0.57.
> So either a user relies on the
Thanks for the clarification regarding the datetimes. Yes let's clear up
any remaining questions offline at Prague. :)
There was some discussion at last week's CI meeting about usage of the
Patchwork /events/ endpoint for polling for patches, and issues with that
process. Here is a relevant blurb, explaining some issues Aaron has run
into using the dpdk-ci repo "poll-pw.sh" shell script:
* Discus
#
May 1, 2025
Attendees
1. Patrick Robb
2. Paul Szczepanek
3. Luca Vizzarro
4. Aaron Conole
#
Minutes
Please disregard the Community Lab DTS failure just reported on this
patchseries. I need to reconfigure the testbed and rerun the test.
On Sun, May 4, 2025 at 1:24 AM Gregory Etelson wrote:
> METER flow action is not supported in MLX5 HWS mode.
> Application must use METER_MARK flow action.
>
>
Please disregard the Community Lab DTS failure just reported on this
patchseries. I need to reconfigure the testbed and rerun the test.
On Fri, May 2, 2025 at 11:26 AM Pillai, Dhanya R
wrote:
> Added log message for ddp package load failure.
>
> mailmap: update contributor entry
>
> Signed-off-b
Please disregard the Community Lab DTS failure just reported on this
patchseries. I need to reconfigure the testbed and rerun the test.
On Fri, May 2, 2025 at 11:11 AM Bruce Richardson
wrote:
> Following discussion earlier on this thread on the previous RFCs and
> patches submitted [1], this ser
Please disregard the Community Lab DTS failure just reported on this
patchseries. I need to reconfigure the testbed and rerun the test.
On Fri, May 2, 2025 at 6:12 AM Kai Ji wrote:
> Remove all decrypt test cases in aesni-mb throughput perf as the
> decrypt throughput testing only support OOP by
Hi, it looks like your patch was affected by an infrastructure issue at the
DPDK Community Lab and has a false failure test result on DPDK patchwork.
Issuing a retest to correct this:
Recheck-request: iol-intel-Functional
Hi, it looks like your patch was affected by an infrastructure issue at the
DPDK Community Lab and has a false failure test result on DPDK patchwork.
Issuing a retest to correct this:
Recheck-request: iol-intel-Functional
Hi, it looks like your patch was affected by an infrastructure issue at the
DPDK Community Lab and has a false failure test result on DPDK patchwork.
Issuing a retest to correct this:
Recheck-request: iol-intel-Functional
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
addre
Recheck-request: iol-intel-Performance
Looks like this patch was affected by an infra failure - putting in a
retest request for the CI testing system.
On Sun, Apr 27, 2025 at 7:28 AM Maayan Kashani wrote:
> Queue sync operation was skipped on rule destroy.
> Unlike on fw wqe rule create in whic
Hello all,
As has been discussed at the DPDK CI Meetings, Shai Brandes of AWS has been
working to set up the infrastructure to do per-patch testing for DPDK on
some AWS x86 and ARM environments. Currently they are doing a DPDK build +
dpdk-test fast tests on those environments, and reporting those
#
April 17, 2025
Attendees
1. Patrick Robb
2. Paul Szczepanek
3. Luca Vizzarro
4. Aaron Conole
5. Manit Mahajan
#
Minutes
#
April 24, 2025
Attendees
* Patrick Robb
* Luca Vizzarro
* Paul Szczepanek
#
Minutes
Thanks for this series Luca. Dean did a review earlier and I have just done
one so we're almost good to proceed. I should probably apply it and do a
testrun before merging, which should be possible tomorrow (Friday).
I will flag that when I tried to apply the series, git complained of a sha1
issue
Reviewed-by: Patrick Robb
Reviewed-by: Patrick Robb
Reviewed-by: Patrick Robb
Reviewed-by: Patrick Robb
Reviewed-by: Patrick Robb
>
>
Reviewed-by: Patrick Robb
Reviewed-by: Patrick Robb
On Wed, Apr 23, 2025 at 9:48 PM Patrick Robb wrote:
> From: Jeremy Spewock
>
Should add:
@requires(topology_type=TopologyType.two_links)
> +class TestPortControl(TestSuite):
> +"""DPDK Port Control Testing Suite."""
> +
> +def send_pack
Reviewed-by: Patrick Robb
Tested-by: Patrick Robb
Applied to next-dts, thanks.
Applied to next-net, thanks.
>
size before I push
Reviewed-by: Patrick Robb
Tested-by: Patrick Robb
All tests are passing now:
https://lab.dpdk.org/results/dashboard/patchsets/33044/
Again, sorry about the oversight.
On Wed, Apr 23, 2025 at 4:40 PM Patrick Robb wrote:
> Hi Nitin,
>
> At the DPDK Community Lab, we inadvertently let CI testing on your patch
> run concurrently with
is not supported by all devices and does not
expose a capability regarding if it is through testpmd.
Signed-off-by: Jeremy Spewock
Signed-off-by: Patrick Robb
Tested-by: Patrick Robb
---
dts/framework/config/conf_yaml_schema.json | 0
dts/tests/TestSuite_port_control.py| 105
developers to have more control over the state of the ports that
testpmd is aware of.
Signed-off-by: Jeremy Spewock
Signed-off-by: Patrick Robb
Tested-by: Patrick Robb
---
dts/framework/remote_session/testpmd_shell.py | 18 ++
1 file changed, 18 insertions(+)
diff --git a/dts
This series ports over most of the test coverage provided from the
port_control testing suite in the Old DTS framework. The only
functionality that is missing is testing port functions in a VM through
QEMU and testing the support of resetting ports. Since we have no
method of handling virtual machi
1 - 100 of 518 matches
Mail list logo
