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

["Juraj Linkeš" <juraj.linkes@pantheon.tech>]

On 6. 9. 2024 18:46, Luca Vizzarro wrote:
> On 23/08/2024 13:16, Juraj Linkeš wrote:
>> As Jeremy mentioned, adding the verify argument may be worthwhile, but 
>> maybe only if we actually identify a usecase where we wouldn't want to 
>> do the verification.
> 
> Yeah, as I pointed out, it feels unlikely to pretend that they are 
> started (or stopped). I think that could cause my unpredicted behaviour 
> and confusion. But also as said already, it can always be added on demand.
> 
>> I also have two other points:
>> 1. Do we want a decorator that does both - starting and stopping? Is 
>> the idea to have all methods that require a certain state to be 
>> decorated and in that case we don't need this? E.g. if there are 
>> multiple configuration steps, only the first one stops the ports (if 
>> started) and we start the ports only when a method needs that (such as 
>> starting pkt fwd)? I think this workflow should be documented in the 
>> class docstring (the important part being that starting and stopping 
>> of ports is done automatically).
> 
> The way I envisioned these decorators is by using a lazy approach. I 
> don't think it may be right to eagerly restart ports after stopping 
> them, because maybe we want to run another command after that will stop 
> them again. So only start and stop as needed. Ideally every port that 
> requires a specific state of the ports need to be decorated. I went 
> through all the methods in the class to check which would and which 
> wouldn't, and it seems alright like this.
> 

I agree. I was initially thinking about this from the point of view of 
making sure we don't change things for other users, but that doesn't 
apply here, as we control the whole testpmd workflow. Your approach is 
actually great - simple and effective.

>> 2. Do we want decorators that start/stop just one port? I guess this 
>> is basically useless with the above workflow.
> 
> Would it actually matter? We are not really using the other ports in 
> parallel here I believe. May bring unnecessary complexity. I am thinking 
> that maybe if needed it could be added later.

I think the only benefit would be that we're sending less commands so 
it'll be a bit faster. Maybe we just make a mental note of this for the 
future.