Re: [PATCH v2 5/5] dts: add testpmd set ports queues

[Luca Vizzarro <Luca.Vizzarro@arm.com>]

On 09/08/2024 16:14, Jeremy Spewock wrote:
> On Tue, Aug 6, 2024 at 8:49 AM Luca Vizzarro <luca.vizzarro@arm.com> wrote:
>>
>> Add a facility to update the number of TX/RX queues during the runtime
>> of testpmd.
>>
>> Signed-off-by: Luca Vizzarro <luca.vizzarro@arm.com>
>> Reviewed-by: Paul Szczepanek <paul.szczepanek@arm.com>
>> ---
>>   dts/framework/remote_session/testpmd_shell.py | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/dts/framework/remote_session/testpmd_shell.py b/dts/framework/remote_session/testpmd_shell.py
>> index ca24b28070..85fbc42696 100644
>> --- a/dts/framework/remote_session/testpmd_shell.py
>> +++ b/dts/framework/remote_session/testpmd_shell.py
>> @@ -805,6 +805,22 @@ def start_all_ports(self, verify: bool = True) -> None:
>>
>>           self.ports_started = True
>>
>> +    @requires_stopped_ports
>> +    def set_ports_queues(self, number_of: int) -> None:
> 
> Was there a reason to not add a verify option to this method? It seems
> like it could be useful, and the general pattern with testpmd methods
> so far is verifying the outcome wherever we can.

Yes, I've noticed that the value (in show port info) doesn't get updated 
until actually restarting the ports. So it wouldn't work here 
unfortunately. Internally it looks like it's only updating a variable, 
the actual operation can only be verified upon ports starting.

>> +        """Sets the number of queues per port.
>> +
>> +        Args:
>> +            number_of: The number of RX/TX queues to create per port.
> 
> Is there any value in allowing users to set either Rx or Tx rather
> than enforcing they change both? I guess I can't think of a specific
> reason to do one and not the other off the top of my head, but it
> seems like the option could be useful.

My initial code was only updating the RX queues for my l2fwd test suite, 
and I was having lots of unpredictable and flaky behaviour. Sometimes it 
would work other times it wouldn't. When setting different values for RX 
and TX queues you actually get a warning from the driver to expect 
unexpected behaviour by doing this. And indeed I did get it. From this I 
gathered that we don't want to have different values, unless we 
explicitly want to make the drivers unhappy. I had unexpected and 
different behaviour on both ice and mlx5_core.

> I might be more in favor of this being an
> InteractiveCommandExecutionError or some other DTSError just to have a
> little more control over the error codes and to make it more clear
> that the error came specifically from the framework.

I noticed you already gave yourself an answer :D