[dpdk-dev] [PATCH v2] app/testpmd: fix txonly mode timestamp intitialization

[Ferruh Yigit]

On 7/29/2020 3:07 PM, Phil Yang wrote:
>> -----Original Message-----
>> From: Viacheslav Ovsiienko <viacheslavo at mellanox.com>
>> Sent: Wednesday, July 29, 2020 8:30 PM
>> To: dev at dpdk.org
>> Cc: matan at mellanox.com; rasland at mellanox.com; thomas at monjalon.net;
>> ferruh.yigit at intel.com; Phil Yang <Phil.Yang at arm.com>
>> Subject: [PATCH v2] app/testpmd: fix txonly mode timestamp intitialization
>>
>> The testpmd application forwards data in multiple threads.
>> In the txonly mode the Tx timestamps must be initialized
>> on per thread basis to provide phase shift for the packet
>> burst being sent. This per thread initialization was performed
>> on zero value of the variable in thread local storage and
>> happened only once after testpmd forwarding start. Executing
>> "start" and "stop" commands did not cause thread local variables
>> zeroing and wrong timestamp values were used.
>>
>> Fixes: 4940344dab1d ("app/testpmd: add Tx scheduling command")
>>
>> Signed-off-by: Viacheslav Ovsiienko <viacheslavo at mellanox.com>
> 
> It looks good to me. 
> 
> Reviewed-by: Phil Yang <phil.yang at arm.com>
> 

Applied to dpdk-next-net/master, thanks.


Overall concern with Tx scheduling code is testing. For the issues like this.

It can be enabled only for 'octeontx2' & 'mlx5', which implements '.read_clock',
and it really can be only used by 'mlx5' because of the mbuf dynamic field.

So only 'mlx5' can use and test it.

What happens when mellanox stops testing it?
Is there any DTS implementation to help others to test or at least to document
how to test it and to document the intention of the feature?