From: Jeremy Spewock <jspewock@iol.unh.edu>
To: Nicholas Pratte <npratte@iol.unh.edu>
Cc: yoan.picchi@foss.arm.com, luca.vizzarro@arm.com,
probb@iol.unh.edu, paul.szczepanek@arm.com,
Honnappa.Nagarahalli@arm.com, juraj.linkes@pantheon.tech,
dmarx@iol.unh.edu, alex.chapman@arm.com, dev@dpdk.org
Subject: Re: [PATCH v1 1/3] dts: rework port attributes in config module
Date: Wed, 4 Sep 2024 14:18:01 -0400 [thread overview]
Message-ID: <CAAA20UT=qhwJEuJLuXFT57qGjx8cNzO8_k62ag4soYXxS6wevA@mail.gmail.com> (raw)
In-Reply-To: <20240821184305.28028-3-npratte@iol.unh.edu>
On Wed, Aug 21, 2024 at 2:43 PM Nicholas Pratte <npratte@iol.unh.edu> wrote:
<snip>
> diff --git a/dts/framework/config/__init__.py b/dts/framework/config/__init__.py
> index df60a5030e..534821ed22 100644
> --- a/dts/framework/config/__init__.py
> +++ b/dts/framework/config/__init__.py
> @@ -151,11 +151,10 @@ class PortConfig:
> """
>
> node: str
> + name: str
> pci: str
> os_driver_for_dpdk: str
> os_driver: str
> - peer_node: str
> - peer_pci: str
>
> @classmethod
> def from_dict(cls, node: str, d: PortConfigDict) -> Self:
> @@ -487,12 +486,19 @@ def from_dict(
> system_under_test_node, SutNodeConfiguration
> ), f"Invalid SUT configuration {system_under_test_node}"
>
> - tg_name = d["traffic_generator_node"]
> + tg_name = d["traffic_generator_node"]["node_name"]
> assert tg_name in node_map, f"Unknown TG {tg_name} in test run {d}"
> traffic_generator_node = node_map[tg_name]
> assert isinstance(
> traffic_generator_node, TGNodeConfiguration
> ), f"Invalid TG configuration {traffic_generator_node}"
> + assert len(traffic_generator_node.ports) == len(
> + system_under_test_node.ports
> + ), "Insufficient ports defined on nodes."
Do we want to assert that the list of ports on the tester is the same
as the number on the SUT, or would it be better here to assert that
the same number of SUT and TG ports are present in the test_run?
There could be a case where a TG is the generator for multiple SUT
hosts and therefore maybe the TG has 4 ports, but each of the SUT
nodes only has 2 which would get flagged as invalid in this assertion.
Maybe something better to compare here is the length of
d["traffic_generator_node"]["test_bed"] and
d["system_under_test_node"]["test_bed"].
> + for port_name in d["system_under_test_node"]["test_bed"]:
> + assert port_name in {port.name: port for port in system_under_test_node.ports}
A little nit-picky, but you could achieve the same thing here using a
list rather than a dictionary here that might be a little easier to
read since we don't need the port info anyway:
assert port_name in [port.name for port in system_under_test_node.ports]
> + for port_name in d["traffic_generator_node"]["test_bed"]:
> + assert port_name in {port.name: port for port in traffic_generator_node.ports}
>
> vdevs = (
> d["system_under_test_node"]["vdevs"] if "vdevs" in d["system_under_test_node"] else []
<snip>
> 2.44.0
>
next prev parent reply other threads:[~2024-09-04 18:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 18:43 [PATCH v1 0/3] dts: rework topology definition in dts config Nicholas Pratte
2024-08-21 18:43 ` [PATCH v1 1/3] dts: rework port attributes in config module Nicholas Pratte
2024-09-04 18:18 ` Jeremy Spewock [this message]
2024-09-10 10:11 ` Juraj Linkeš
2024-10-29 16:52 ` Dean Marx
2024-08-21 18:43 ` [PATCH v1 2/3] dts: rework testbed_model Port objects to contain unique identifiers Nicholas Pratte
2024-09-04 18:18 ` Jeremy Spewock
2024-09-10 10:17 ` Juraj Linkeš
2024-10-29 16:53 ` Dean Marx
2024-08-21 18:43 ` [PATCH v1 3/3] dts: rework test suite and dts runner to include test_run configs Nicholas Pratte
2024-09-04 18:18 ` Jeremy Spewock
2024-09-10 11:05 ` Juraj Linkeš
2024-09-27 14:38 ` Jeremy Spewock
2024-10-29 17:00 ` Dean Marx
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAA20UT=qhwJEuJLuXFT57qGjx8cNzO8_k62ag4soYXxS6wevA@mail.gmail.com' \
--to=jspewock@iol.unh.edu \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=alex.chapman@arm.com \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=juraj.linkes@pantheon.tech \
--cc=luca.vizzarro@arm.com \
--cc=npratte@iol.unh.edu \
--cc=paul.szczepanek@arm.com \
--cc=probb@iol.unh.edu \
--cc=yoan.picchi@foss.arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).