From: Luca Vizzarro <Luca.Vizzarro@arm.com>
To: "Juraj Linkeš" <juraj.linkes@pantheon.tech>,
"Jeremy Spewock" <jspewock@iol.unh.edu>
Cc: dev@dpdk.org, Jack Bond-Preston <jack.bond-preston@arm.com>,
Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Subject: Re: [PATCH 3/6] dts: add testpmd shell params
Date: Wed, 10 Apr 2024 11:49:29 +0100 [thread overview]
Message-ID: <9dd740f0-a409-4dc1-a6c4-9a71836f4789@arm.com> (raw)
In-Reply-To: <CAOb5WZaadMs_xuuaGJCb=Q9y=itqvmzKoKfGWnUNjs=d0gEuHg@mail.gmail.com>
On 09/04/2024 17:37, Juraj Linkeš wrote:
> As Jeremy pointed out, going forward, this is likely to become bloated
> and moving it to params.py (for example) may be better.
>
> There's a lot of testpmd args here. I commented on the implementation
> of some of them. I didn't verify that the actual values match the docs
> or, god forbid, tested all of it. :-) Doing that as we start using
> them is going to be good enough.
It is indeed a lot of args. I double checked most of them, so it should
be mostly correct, but unfortunately I am not 100% sure. I did notice
discrepancies between the docs and the source code of testpmd too.
Although not ideal, I am inclining to update the definitions whenever a
newly implemented test case hits a roadblock.
One thing that I don't remember if I mentioned so far, is the "XYPair".
You see --flag=X,[Y] in the docs, but I am sure to have read somewhere
this is potentially just a comma-separated multiple value.
> On Tue, Mar 26, 2024 at 8:04 PM Luca Vizzarro <luca.vizzarro@arm.com> wrote:
>>
>> Implement all the testpmd shell parameters into a data structure.
>>
>> Signed-off-by: Luca Vizzarro <luca.vizzarro@arm.com>
>> Reviewed-by: Jack Bond-Preston <jack.bond-preston@arm.com>
>> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
>> ---
>> dts/framework/remote_session/testpmd_shell.py | 633 +++++++++++++++++-
>> 1 file changed, 615 insertions(+), 18 deletions(-)
>>
>> diff --git a/dts/framework/remote_session/testpmd_shell.py b/dts/framework/remote_session/testpmd_shell.py
>> index db3abb7600..a823dc53be 100644
>> --- a/dts/framework/remote_session/testpmd_shell.py
>> +++ b/dts/framework/remote_session/testpmd_shell.py
>
> <snip>
>
>> +@str_mixins(bracketed, comma_separated)
>> +class TestPmdRingNUMAConfig(NamedTuple):
>> + """Tuple associating DPDK port, direction of the flow and NUMA socket."""
>
> Is there any particular order for these various classes?
No, there is no actual order, potential dependencies aside.
>> +
>> + port: int
>> + direction: TestPmdFlowDirection
>> + socket: int
>> +
>> +
>
> <snip>
>
>> +@dataclass(kw_only=True)
>> +class TestPmdTXOnlyForwardingMode(Params):
>
> The three special forwarding modes should really be moved right after
> TestPmdForwardingModes. Do we actually need these three in
> TestPmdForwardingModes? Looks like we could just remove those from
> TestPmdForwardingModes since they have to be passed separately, not as
> that Enum.
Can move and no we don't really need them in TestPmdForwardingModes,
they can be hardcoded in their own special classes.
>> + __forward_mode: Literal[TestPmdForwardingModes.txonly] = field(
>> + default=TestPmdForwardingModes.txonly, init=False, metadata=long("forward-mode")
>> + )
>
> I guess this is here so that "--forward-mode=txonly" gets rendered,
> right? Why the two underscored? Is that because we want to hammer home
> the fact that this is init=False, a kind of internal field? I'd like
> to make it like the other fields, without any underscores (or maybe
> just one underscore), and documented (definitely documented).
> If we remove txonly from the Enum, we could just have the string value
> here. The Enums are mostly useful to give users the proper range of
> values.
>
Correct and correct. A double underscore would ensure no access to this
field, which is fixed and only there for rendering purposes... (also the
developer doesn't get a hint from the IDE, at least not on VS code) and
in the case of TestPmdForwardingModes it would remove a potential
conflict. It can definitely be documented though.
>> + multi_flow: Option = field(default=None, metadata=long("txonly-multi-flow"))
>> + """Generate multiple flows."""
>> + segments_length: XYPair | None = field(default=None, metadata=long("txpkts"))
>> + """Set TX segment sizes or total packet length."""
>> +
>> +
>> +@dataclass(kw_only=True)
>> +class TestPmdFlowGenForwardingMode(Params):
>> + __forward_mode: Literal[TestPmdForwardingModes.flowgen] = field(
>> + default=TestPmdForwardingModes.flowgen, init=False, metadata=long("forward-mode")
>> + )
>> + clones: int | None = field(default=None, metadata=long("flowgen-clones"))
>> + """Set the number of each packet clones to be sent. Sending clones reduces host CPU load on
>> + creating packets and may help in testing extreme speeds or maxing out Tx packet performance.
>> + N should be not zero, but less than ‘burst’ parameter.
>> + """
>> + flows: int | None = field(default=None, metadata=long("flowgen-flows"))
>> + """Set the number of flows to be generated, where 1 <= N <= INT32_MAX."""
>> + segments_length: XYPair | None = field(default=None, metadata=long("txpkts"))
>> + """Set TX segment sizes or total packet length."""
>> +
>> +
>> +@dataclass(kw_only=True)
>> +class TestPmdNoisyForwardingMode(Params):
>> + __forward_mode: Literal[TestPmdForwardingModes.noisy] = field(
>> + default=TestPmdForwardingModes.noisy, init=False, metadata=long("forward-mode")
>> + )
>
> Are both of __forward_mode and forward_mode needed because we need to
> render both?
Yes, this would render as `--forward-mode=noisy --noisy-forward-mode=io`
using IO as example.
>> + forward_mode: (
>> + Literal[
>> + TestPmdForwardingModes.io,
>> + TestPmdForwardingModes.mac,
>> + TestPmdForwardingModes.macswap,
>> + TestPmdForwardingModes.fivetswap,
>> + ]
>> + | None
>
> Is there a difference between using union (TestPmdForwardingModes.io |
> TestPmdForwardingModes.mac etc.) and Literal?
TestPmdForwardingModes.io etc are literals and mypy complains:
error: Invalid type: try using Literal[TestPmdForwardingModes.io]
instead? [misc]
Therefore they need to be wrapped in Literal[..]
Literal[A, B] is the equivalent of Union[Literal[A], Literal[B]]
So this ultimately renders as Union[Lit[io], Lit[mac], Lit[macswap],
Lit[fivetswap], None]. So it's really a matter of conciseness, by using
Literal[A, ..], vs intuitiveness, by using Literal[A] | Literal[..] | ..
Which one would we prefer?
>> +@dataclass
>> +class TestPmdDisableRSS(Params):
>> + """Disable RSS (Receive Side Scaling)."""
>
> Let's put the explanation/reminder of what RSS stands for to either
> all three classes or none of them.
>
Ack.
>> + rss: TestPmdDisableRSS | TestPmdSetRSSIPOnly | TestPmdSetRSSUDP | None = None
>> + """RSS option setting.
>> +
>> + The value can be one of:
>> + * :class:`TestPmdDisableRSS`, to disable RSS
>> + * :class:`TestPmdSetRSSIPOnly`, to set RSS for IPv4/IPv6 only
>> + * :class:`TestPmdSetRSSUDP`, to set RSS for IPv4/IPv6 and UDP
>> + """
>
> Have you thought about making an Enum where values would be these
> classes? That could simplify things a bit for users if it works.
It would be lovely to have classes as enum values, and I thought of it
thinking of other languages like Rust. Not sure this is possible in
Python. Are you suggesting to pass a class type as a value? In the hope
that doing:
TestPmdRSS.Disable()
could work? As this wouldn't. What works instead is:
TestPmdRSS.Disable.value()
Which is somewhat ugly. Maybe I could modify the behaviour of the enum
to return the underlying value instead of a reference to the field.
Do you have any better ideas?
>> +
>> + forward_mode: (
>> + Literal[
>> + TestPmdForwardingModes.io,
>> + TestPmdForwardingModes.mac,
>> + TestPmdForwardingModes.macswap,
>> + TestPmdForwardingModes.rxonly,
>> + TestPmdForwardingModes.csum,
>> + TestPmdForwardingModes.icmpecho,
>> + TestPmdForwardingModes.ieee1588,
>> + TestPmdForwardingModes.fivetswap,
>> + TestPmdForwardingModes.shared_rxq,
>> + TestPmdForwardingModes.recycle_mbufs,
>> + ]
>
> This could result in just TestPmdForwardingModes | the rest if we
> remove the compound fw modes from TestPmdForwardingModes. Maybe we
> could rename TestPmdForwardingModes to TestPmdSimpleForwardingModes or
> something at that point.
Yes, good idea.
>> + | TestPmdFlowGenForwardingMode
>> + | TestPmdTXOnlyForwardingMode
>> + | TestPmdNoisyForwardingMode
>> + | None
>> + ) = TestPmdForwardingModes.io
>> + """Set the forwarding mode.
>
> <snip>
>
>> + mempool_allocation_mode: (
>> + Literal[
>> + TestPmdMempoolAllocationMode.native,
>> + TestPmdMempoolAllocationMode.xmem,
>> + TestPmdMempoolAllocationMode.xmemhuge,
>> + ]
>> + | TestPmdAnonMempoolAllocationMode
>> + | None
>
> This looks similar to fw modes, maybe the same applies here as well.
Ack.
>> + ) = field(default=None, metadata=long("mp-alloc"))
>> + """Select mempool allocation mode.
>> +
>> + The value can be one of:
>> + * :attr:`TestPmdMempoolAllocationMode.native`
>> + * :class:`TestPmdAnonMempoolAllocationMode`
>> + * :attr:`TestPmdMempoolAllocationMode.xmem`
>> + * :attr:`TestPmdMempoolAllocationMode.xmemhuge`
>> + """
next prev parent reply other threads:[~2024-04-10 10:49 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-26 19:04 [PATCH 0/6] dts: add testpmd params and statefulness Luca Vizzarro
2024-03-26 19:04 ` [PATCH 1/6] dts: add parameters data structure Luca Vizzarro
2024-03-28 16:48 ` Jeremy Spewock
2024-04-09 15:52 ` Luca Vizzarro
2024-04-09 12:10 ` Juraj Linkeš
2024-04-09 16:28 ` Luca Vizzarro
2024-04-10 9:15 ` Juraj Linkeš
2024-04-10 9:51 ` Luca Vizzarro
2024-04-10 10:04 ` Juraj Linkeš
2024-03-26 19:04 ` [PATCH 2/6] dts: use Params for interactive shells Luca Vizzarro
2024-03-28 16:48 ` Jeremy Spewock
2024-04-09 14:56 ` Juraj Linkeš
2024-04-10 9:34 ` Luca Vizzarro
2024-04-10 9:58 ` Juraj Linkeš
2024-03-26 19:04 ` [PATCH 3/6] dts: add testpmd shell params Luca Vizzarro
2024-03-28 16:48 ` Jeremy Spewock
2024-04-09 16:37 ` Juraj Linkeš
2024-04-10 10:49 ` Luca Vizzarro [this message]
2024-04-10 13:17 ` Juraj Linkeš
2024-03-26 19:04 ` [PATCH 4/6] dts: use testpmd params for scatter test suite Luca Vizzarro
2024-04-09 19:12 ` Juraj Linkeš
2024-04-10 10:53 ` Luca Vizzarro
2024-04-10 13:18 ` Juraj Linkeš
2024-04-26 18:06 ` Jeremy Spewock
2024-04-29 7:45 ` Juraj Linkeš
2024-03-26 19:04 ` [PATCH 5/6] dts: add statefulness to InteractiveShell Luca Vizzarro
2024-03-28 16:48 ` Jeremy Spewock
2024-04-10 6:53 ` Juraj Linkeš
2024-04-10 11:27 ` Luca Vizzarro
2024-04-10 13:35 ` Juraj Linkeš
2024-04-10 14:07 ` Luca Vizzarro
2024-04-12 12:33 ` Juraj Linkeš
2024-04-29 14:48 ` Jeremy Spewock
2024-03-26 19:04 ` [PATCH 6/6] dts: add statefulness to TestPmdShell Luca Vizzarro
2024-03-28 16:48 ` Jeremy Spewock
2024-04-10 7:41 ` Juraj Linkeš
2024-04-10 11:35 ` Luca Vizzarro
2024-04-11 10:30 ` Juraj Linkeš
2024-04-11 11:47 ` Luca Vizzarro
2024-04-11 12:13 ` Juraj Linkeš
2024-04-11 13:59 ` Luca Vizzarro
2024-04-26 18:06 ` Jeremy Spewock
2024-04-29 12:06 ` Juraj Linkeš
2024-04-10 7:50 ` Juraj Linkeš
2024-04-10 11:37 ` Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 0/8] dts: add testpmd params Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 1/8] dts: add params manipulation module Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 2/8] dts: use Params for interactive shells Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 3/8] dts: refactor EalParams Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 4/8] dts: remove module-wide imports Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 5/8] dts: add testpmd shell params Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 6/8] dts: use testpmd params for scatter test suite Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 7/8] dts: rework interactive shells Luca Vizzarro
2024-05-09 11:20 ` [PATCH v2 8/8] dts: use Unpack for type checking and hinting Luca Vizzarro
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=9dd740f0-a409-4dc1-a6c4-9a71836f4789@arm.com \
--to=luca.vizzarro@arm.com \
--cc=dev@dpdk.org \
--cc=honnappa.nagarahalli@arm.com \
--cc=jack.bond-preston@arm.com \
--cc=jspewock@iol.unh.edu \
--cc=juraj.linkes@pantheon.tech \
/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).