On 09/08/2024 16:13, Jeremy Spewock wrote:
I tried to address this very same problem in the scatter expansion
patch series but, admittedly, I like your approach better. There is
one thing that Juraj and I discussed on that thread however that is
probably worth noting here regarding verification of the stopping and
starting ports. The main idea behind that being if the user calls a
testpmd method and specifically specifies they don't want to verify
the outcome of that method, but then we still verify whether we
stopped the ports or not, that could cause confusion. The compromise
we ended up settling for was just to make a parameter to the decorator
that allows you to statically decide which decorated methods should
verify the ports stopping and which shouldn't. It was mainly because
of the ability to specify "verify" as a kwarg or an arg and the types
being messy. The discussion we had about it starts here if you were
interested in reading it:
http://inbox.dpdk.org/dev/dff89e16-0173-4069-878c-d1c34df1a...@pantheon.tech/
When it comes to starting and stopping ports, we may need to ensure that
the operations were done correctly. Surely we don't want to start
forwarding thinking that the ports are initialised, when they could be
not... I guess the point here is that it may be important to save the
correct state. Not sure, I guess verify could always be added later if
needed.
On Tue, Aug 6, 2024 at 8:49 AM Luca Vizzarro <luca.vizza...@arm.com> wrote:
Add testpmd commands to start and stop all the ports, so that they can
be configured. Because there is a distinction of commands that require
the ports to be stopped and started, also add decorators for commands
that require a specific state, removing this logic from the test
writer's duty.
Signed-off-by: Luca Vizzarro <luca.vizza...@arm.com>
Reviewed-by: Paul Szczepanek <paul.szczepa...@arm.com>
---
<snip>
+P = ParamSpec("P")
+TestPmdShellMethod = Callable[Concatenate["TestPmdShell", P], Any]
Agggh, I spent so much time trying to figure out how to do exactly
this when I was working on the scatter series but I couldn't get a
nice typehint while specifying that I wanted a TestPmdShell first. I
had no idea that Concatenate was a type but I will definitely keep
that one in mind.
Glad I could help! :D
+def requires_started_ports(func: TestPmdShellMethod) -> TestPmdShellMethod:
+ """Decorator for :class:`TestPmdShell` commands methods that require
started ports.
+
+ If the decorated method is called while the ports are stopped, then these
are started before
+ continuing.
+ """
+
+ @functools.wraps(func)
+ def _wrapper(self: "TestPmdShell", *args: P.args, **kwargs: P.kwargs):
+ if not self.ports_started:
+ self._logger.debug("Ports need to be started to continue")
+ self.start_all_ports()
+
+ return func(self, *args, **kwargs)
+
+ return _wrapper
+
I'm not sure how much it is necessary since it is pretty clear what
these decorators are trying to do with the parameter, but since these
are public methods I think not having an "Args:" section for the func
might trip up the doc generation.
We have several methods that have one-liner docstrings... so not really
sure. I was hoping to have the doc generation merged as testing what's
correct and what's not is currently complicated.
+ self.ports_started = not self._app_params.disable_device_start
+
It might be useful to add this attribute as a stub in the class just
to be clear on the typing. It also helps me understand things at more
of a glance personally.
You make a fair point here.
