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.
