diff mbox series

[v2] app/testpmd: fix txonly mode timestamp intitialization

Message ID 1596025794-26599-1-git-send-email-viacheslavo@mellanox.com (mailing list archive)
State Accepted, archived
Delegated to: Ferruh Yigit
Headers
Series [v2] app/testpmd: fix txonly mode timestamp intitialization |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS

Commit Message

Slava Ovsiienko July 29, 2020, 12:29 p.m. UTC 
  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@mellanox.com>

---
v1->v2: On mailing list comments addressing:
    - removed unnecessary volatile qualifier
    - comment added about the barrier
---
 app/test-pmd/txonly.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comments

Phil Yang July 29, 2020, 2:07 p.m. UTC | #1 
> -----Original Message-----
> From: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> Sent: Wednesday, July 29, 2020 8:30 PM
> To: dev@dpdk.org
> Cc: matan@mellanox.com; rasland@mellanox.com; thomas@monjalon.net;
> ferruh.yigit@intel.com; Phil Yang <Phil.Yang@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@mellanox.com>

It looks good to me. 

Reviewed-by: Phil Yang <phil.yang@arm.com>

Thanks,
Phil

<...>
Ferruh Yigit July 29, 2020, 3:29 p.m. UTC | #2 
On 7/29/2020 3:07 PM, Phil Yang wrote:
>> -----Original Message-----
>> From: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
>> Sent: Wednesday, July 29, 2020 8:30 PM
>> To: dev@dpdk.org
>> Cc: matan@mellanox.com; rasland@mellanox.com; thomas@monjalon.net;
>> ferruh.yigit@intel.com; Phil Yang <Phil.Yang@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@mellanox.com>
> 
> It looks good to me. 
> 
> Reviewed-by: Phil Yang <phil.yang@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?
diff mbox series

Patch

diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index 97f4a45..fe28bdb0 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -55,9 +55,12 @@ 
 static struct rte_udp_hdr pkt_udp_hdr; /**< UDP header of tx packets. */
 RTE_DEFINE_PER_LCORE(uint64_t, timestamp_qskew);
 					/**< Timestamp offset per queue */
+RTE_DEFINE_PER_LCORE(uint32_t, timestamp_idone); /**< Timestamp init done. */
+
 static uint64_t timestamp_mask; /**< Timestamp dynamic flag mask */
 static int32_t timestamp_off; /**< Timestamp dynamic field offset */
 static bool timestamp_enable; /**< Timestamp enable */
+static uint32_t timestamp_init_req; /**< Timestamp initialization request. */
 static uint64_t timestamp_initial[RTE_MAX_ETHPORTS];
 
 static void
@@ -229,7 +232,8 @@ 
 			rte_be64_t ts;
 		} timestamp_mark;
 
-		if (unlikely(!skew)) {
+		if (unlikely(timestamp_init_req !=
+			RTE_PER_LCORE(timestamp_idone))) {
 			struct rte_eth_dev *dev = &rte_eth_devices[fs->tx_port];
 			unsigned int txqs_n = dev->data->nb_tx_queues;
 			uint64_t phase = tx_pkt_times_inter * fs->tx_queue /
@@ -241,6 +245,7 @@ 
 			skew = timestamp_initial[fs->tx_port] +
 			       tx_pkt_times_inter + phase;
 			RTE_PER_LCORE(timestamp_qskew) = skew;
+			RTE_PER_LCORE(timestamp_idone) = timestamp_init_req;
 		}
 		timestamp_mark.pkt_idx = rte_cpu_to_be_16(idx);
 		timestamp_mark.queue_idx = rte_cpu_to_be_16(fs->tx_queue);
@@ -426,6 +431,10 @@ 
 			   timestamp_mask &&
 			   timestamp_off >= 0 &&
 			   !rte_eth_read_clock(pi, &timestamp_initial[pi]);
+	if (timestamp_enable)
+		timestamp_init_req++;
+	/* Make sure all settings are visible on forwarding cores.*/
+	rte_wmb();
 }
 
 struct fwd_engine tx_only_engine = {