From: Patrick Robb <probb@iol.unh.edu>
To: Nicholas Pratte <npratte@iol.unh.edu>
Cc: ian.stokes@intel.com, yoan.picchi@foss.arm.com,
paul.szczepanek@arm.com, Honnappa.Nagarahalli@arm.com,
thomas@monjalon.net, luca.vizzarro@arm.com,
thomas.wilks@arm.com, dmarx@iol.unh.edu,
stephen@networkplumber.org, dev@dpdk.org
Subject: Re: [RFC Patch v1 4/5] dts: add trex traffic generator to dts framework
Date: Thu, 15 May 2025 15:25:15 -0400 [thread overview]
Message-ID: <CAJvnSUBt4D=jvYcbZacN1kDXL6pmukVeVq=g5XbkvwPG2b4tZw@mail.gmail.com> (raw)
In-Reply-To: <20250423194011.1447679-5-npratte@iol.unh.edu>
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
On Wed, Apr 23, 2025 at 3:40 PM Nicholas Pratte <npratte@iol.unh.edu> wrote:
> Implement the TREX traffic generator for use in the DTS framework. The
> provided implementation leverages TREX's stateless API automation
> library, via use of a Python shell. As such, version control of TREX may
> be needed. The DTS context has been modified to include a performance
> traffic generator in addition to a functional traffic generator.
>
I think the statement is that only certain versions are confirmed to work
off of your implementation? I think usage of the term version control is
confusing since we are just talking about using particular versions of
TREX, and not using a "version control" tool like git. This is more about
listing approved versions of the dependency for the TG.
>
>
> dpdk_build_env = DPDKBuildEnvironment(config.dpdk.build, sut_node)
> dpdk_runtime_env = DPDKRuntimeEnvironment(config.dpdk, sut_node,
> dpdk_build_env)
> - traffic_generator =
> create_traffic_generator(config.traffic_generator, tg_node)
> + # There is definitely a better way to do this.
> + tg_dpdk_runtime_env = None
> + if (
> + config.perf_traffic_generator.type ==
> TrafficGeneratorType.TREX
> + or config.func_traffic_generator.type ==
> TrafficGeneratorType.TREX
> + ):
>
We have this from the testrun config
perf: false # disable performance testing
func: true # enable functional testing
So, use if testrunconfig.perf == true?
>
> +
> +@dataclass
> +class TrexPerformanceStats(PerformanceTrafficStats):
> + """Data structure to store performance statistics for a given test
> run.
> +
> + Attributes:
> + packet: The packet that was sent in the test run.
> + frame_size: The total length of the frame. (L2 downward)
> + tx_expected_bps: The expected bits per second on a given NIC.
> + tx_expected_cps: ...
>
"The expected connections per second" ? I think you just missed this one.
> +
> + Attributes:
> + ports: Related ports utilized in TG instance.
> + """
> + super().setup(ports)
> + # Start TREX server process.
> + try:
> + self._logger.info("Starting TREX server process: sending 45
> second sleep.")
> + privileged_command = self._os_session._get_privileged_command(
> + f"""
> + cd /opt/v3.03/; {self._tg_config.remote_path}/t-rex-64
> + --cfg {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 <probb@iol.unh.edu>
[-- Attachment #2: Type: text/html, Size: 4200 bytes --]
next prev parent reply other threads:[~2025-05-15 19:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 19:40 [RFC Patch v1 0/5] Add TREX Traffic Generator to DTS Framework Nicholas Pratte
2025-04-23 19:40 ` [RFC Patch v1 1/5] dts: rework config module to support perf TGs Nicholas Pratte
2025-04-23 19:40 ` [RFC Patch v1 2/5] dts: rework traffic generator inheritance structure Nicholas Pratte
2025-05-15 19:24 ` Patrick Robb
2025-04-23 19:40 ` [RFC Patch v1 3/5] dts: add asychronous support to ssh sessions Nicholas Pratte
2025-05-15 19:24 ` Patrick Robb
2025-04-23 19:40 ` [RFC Patch v1 4/5] dts: add trex traffic generator to dts framework Nicholas Pratte
2025-05-15 19:25 ` Patrick Robb [this message]
2025-04-23 19:40 ` [RFC Patch v1 5/5] dts: add performance test functions to test suite api Nicholas Pratte
2025-05-15 19:25 ` Patrick Robb
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='CAJvnSUBt4D=jvYcbZacN1kDXL6pmukVeVq=g5XbkvwPG2b4tZw@mail.gmail.com' \
--to=probb@iol.unh.edu \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=dev@dpdk.org \
--cc=dmarx@iol.unh.edu \
--cc=ian.stokes@intel.com \
--cc=luca.vizzarro@arm.com \
--cc=npratte@iol.unh.edu \
--cc=paul.szczepanek@arm.com \
--cc=stephen@networkplumber.org \
--cc=thomas.wilks@arm.com \
--cc=thomas@monjalon.net \
--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).