On 7/29/2020 3:07 PM, Phil Yang wrote:
>> -----Original Message-----
>> From: Viacheslav Ovsiienko <viachesl...@mellanox.com>
>> Sent: Wednesday, July 29, 2020 8:30 PM
>> To: dev@dpdk.org
>> Cc: ma...@mellanox.com; rasl...@mellanox.com; tho...@monjalon.net;
>> ferruh.yi...@intel.com; Phil Yang <phil.y...@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 <viachesl...@mellanox.com>
>
> It looks good to me.
>
> Reviewed-by: Phil Yang <phil.y...@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?
