net/mlx5: add timestamp ascending order error statistics
Checks
Commit Message
The ConnectX NICs support packet send scheduling on specified
moment of time. Application can set the desired timestamp value
in dynamic mbuf field and driver will push the special WAIT WQE
to the hardware queue in order to suspend the entire queue
operations till the specified time moment, then PMD pushes the
regular WQE for packet sending.
In the following packets the scheduling can be requested again,
with different timestamps, and driver pushes WAIT WQE accordingly.
The timestamps should be provided by application in ascending
order as packets are queued to the hardware queue, otherwise
hardware would not be able to perform scheduling correctly -
it discovers the WAIT WQEs in order as they were pushed, there is
no any reordering - neither in PMD, not in the NIC, and, obviously,
the regular hardware can't work as time machine and wait for some
elapsed moment in the past.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_tx.h | 5 +++++
drivers/net/mlx5/mlx5_txpp.c | 12 +++++++++---
3 files changed, 15 insertions(+), 3 deletions(-)
Comments
This patch is marked "Awaiting Upstream" in patchwork,
but it doesn't seem merged anywhere.
Please check its status.
20/04/2023 10:18, Viacheslav Ovsiienko:
> The ConnectX NICs support packet send scheduling on specified
> moment of time. Application can set the desired timestamp value
> in dynamic mbuf field and driver will push the special WAIT WQE
> to the hardware queue in order to suspend the entire queue
> operations till the specified time moment, then PMD pushes the
> regular WQE for packet sending.
>
> In the following packets the scheduling can be requested again,
> with different timestamps, and driver pushes WAIT WQE accordingly.
> The timestamps should be provided by application in ascending
> order as packets are queued to the hardware queue, otherwise
> hardware would not be able to perform scheduling correctly -
> it discovers the WAIT WQEs in order as they were pushed, there is
> no any reordering - neither in PMD, not in the NIC, and, obviously,
> the regular hardware can't work as time machine and wait for some
> elapsed moment in the past.
>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Hi,
> -----Original Message-----
> From: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> Sent: Thursday, April 20, 2023 11:19 AM
> To: dev@dpdk.org
> Subject: [PATCH] net/mlx5: add timestamp ascending order error statistics
>
> The ConnectX NICs support packet send scheduling on specified moment of
> time. Application can set the desired timestamp value in dynamic mbuf field
> and driver will push the special WAIT WQE to the hardware queue in order to
> suspend the entire queue operations till the specified time moment, then PMD
> pushes the regular WQE for packet sending.
>
> In the following packets the scheduling can be requested again, with different
> timestamps, and driver pushes WAIT WQE accordingly.
> The timestamps should be provided by application in ascending order as
> packets are queued to the hardware queue, otherwise hardware would not be
> able to perform scheduling correctly - it discovers the WAIT WQEs in order as
> they were pushed, there is no any reordering - neither in PMD, not in the NIC,
> and, obviously, the regular hardware can't work as time machine and wait for
> some elapsed moment in the past.
>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
@@ -1186,6 +1186,7 @@ struct mlx5_dev_txpp {
uint64_t err_clock_queue; /* Clock Queue errors. */
uint64_t err_ts_past; /* Timestamp in the past. */
uint64_t err_ts_future; /* Timestamp in the distant future. */
+ uint64_t err_ts_order; /* Timestamp not in ascending order. */
};
/* Sample ID information of eCPRI flex parser structure. */
@@ -162,6 +162,7 @@ struct mlx5_txq_data {
uint16_t idx; /* Queue index. */
uint64_t rt_timemask; /* Scheduling timestamp mask. */
uint64_t ts_mask; /* Timestamp flag dynamic mask. */
+ uint64_t ts_last; /* Last scheduled timestamp. */
int32_t ts_offset; /* Timestamp field dynamic offset. */
struct mlx5_dev_ctx_shared *sh; /* Shared context. */
struct mlx5_txq_stats stats; /* TX queue counters. */
@@ -1682,6 +1683,10 @@ mlx5_tx_schedule_send(struct mlx5_txq_data *restrict txq,
return MLX5_TXCMP_CODE_EXIT;
/* Convert the timestamp into completion to wait. */
ts = *RTE_MBUF_DYNFIELD(loc->mbuf, txq->ts_offset, uint64_t *);
+ if (txq->ts_last && ts < txq->ts_last)
+ __atomic_fetch_add(&txq->sh->txpp.err_ts_order,
+ 1, __ATOMIC_RELAXED);
+ txq->ts_last = ts;
wqe = txq->wqes + (txq->wqe_ci & txq->wqe_m);
sh = txq->sh;
if (txq->wait_on_time) {
@@ -29,6 +29,7 @@ static const char * const mlx5_txpp_stat_names[] = {
"tx_pp_clock_queue_errors", /* Clock Queue errors. */
"tx_pp_timestamp_past_errors", /* Timestamp in the past. */
"tx_pp_timestamp_future_errors", /* Timestamp in the distant future. */
+ "tx_pp_timestamp_order_errors", /* Timestamp not in ascending order. */
"tx_pp_jitter", /* Timestamp jitter (one Clock Queue completion). */
"tx_pp_wander", /* Timestamp wander (half of Clock Queue CQEs). */
"tx_pp_sync_lost", /* Scheduling synchronization lost. */
@@ -758,6 +759,7 @@ mlx5_txpp_start_service(struct mlx5_dev_ctx_shared *sh)
sh->txpp.err_clock_queue = 0;
sh->txpp.err_ts_past = 0;
sh->txpp.err_ts_future = 0;
+ sh->txpp.err_ts_order = 0;
/* Attach interrupt handler to process Rearm Queue completions. */
fd = mlx5_os_get_devx_channel_fd(sh->txpp.echan);
ret = mlx5_os_set_nonblock_channel_fd(fd);
@@ -1034,6 +1036,7 @@ int mlx5_txpp_xstats_reset(struct rte_eth_dev *dev)
__atomic_store_n(&sh->txpp.err_clock_queue, 0, __ATOMIC_RELAXED);
__atomic_store_n(&sh->txpp.err_ts_past, 0, __ATOMIC_RELAXED);
__atomic_store_n(&sh->txpp.err_ts_future, 0, __ATOMIC_RELAXED);
+ __atomic_store_n(&sh->txpp.err_ts_order, 0, __ATOMIC_RELAXED);
return 0;
}
@@ -1221,9 +1224,12 @@ mlx5_txpp_xstats_get(struct rte_eth_dev *dev,
stats[n_used + 4].value =
__atomic_load_n(&sh->txpp.err_ts_future,
__ATOMIC_RELAXED);
- stats[n_used + 5].value = mlx5_txpp_xstats_jitter(&sh->txpp);
- stats[n_used + 6].value = mlx5_txpp_xstats_wander(&sh->txpp);
- stats[n_used + 7].value = sh->txpp.sync_lost;
+ stats[n_used + 5].value =
+ __atomic_load_n(&sh->txpp.err_ts_order,
+ __ATOMIC_RELAXED);
+ stats[n_used + 6].value = mlx5_txpp_xstats_jitter(&sh->txpp);
+ stats[n_used + 7].value = mlx5_txpp_xstats_wander(&sh->txpp);
+ stats[n_used + 8].value = sh->txpp.sync_lost;
}
return n_used + n_txpp;
}