[PATCH v2 4/5] dts: add ability to start/stop testpmd ports

[Luca Vizzarro]

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-d1c34df1ae13@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.vizzarro at 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.vizzarro at arm.com>
>> Reviewed-by: Paul Szczepanek <paul.szczepanek at 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.