From: Saeed Mahameed <saeed@kernel.org>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
Maxim Mikityanskiy <maximmi@nvidia.com>
Subject: [PATCH net-next 08/16] net/mlx5e: Fix calculations for ICOSQ size
Date: Thu, 29 Sep 2022 00:21:48 -0700 [thread overview]
Message-ID: <20220929072156.93299-9-saeed@kernel.org> (raw)
In-Reply-To: <20220929072156.93299-1-saeed@kernel.org>
From: Maxim Mikityanskiy <maximmi@nvidia.com>
WQEs must not cross page boundaries, they are padded with NOPs if they
don't fit the page. mlx5e_mpwrq_total_umr_wqebbs doesn't take into
account this padding, risking reserving not enough space.
The padding is not straightforward to add to this calculation, because
WQEs of different sizes may be mixed together in the queue. If each page
ends with a big WQE that doesn't fit and requires at most its size minus
1 WQEBB of padding, the total space can be much bigger than in case when
smaller WQEs take advantage of this padding.
Replace the wrong exact calculation by the following estimation. Each
padding can be at most the size of the maximum WQE used in the queue
minus one WQEBB. Let's call the rest of the page "useful space". If we
divide the total size of all needed WQEs by this useful space, rounding
up, we'll get the number of pages, which is enough to contain all these
WQEs. It's correct, because every WQE that appeared on the boundary
between two blocks of useful space would start in the useful space of
one page and end in the padding of the same page, while our estimation
reserved space for its tail in the next space, making the estimation not
smaller than the real space occupied in the queue.
The code actually uses a looser estimation: instead of taking the
maximum size of all used WQE types minus 1 WQEBB, it takes the maximum
hardware size of a WQE. It's made for simplicity and extensibility.
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/en/params.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
index 0f18031a871a..68bc66cbd8a5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
@@ -951,7 +951,7 @@ static u8 mlx5e_build_icosq_log_wq_sz(struct mlx5_core_dev *mdev,
struct mlx5e_params *params,
struct mlx5e_rq_param *rqp)
{
- u32 wqebbs;
+ u32 wqebbs, total_pages, useful_space;
/* MLX5_WQ_TYPE_CYCLIC */
if (params->rq_wq_type != MLX5_WQ_TYPE_LINKED_LIST_STRIDING_RQ)
@@ -998,6 +998,18 @@ static u8 mlx5e_build_icosq_log_wq_sz(struct mlx5_core_dev *mdev,
if (params->packet_merge.type == MLX5E_PACKET_MERGE_SHAMPO)
wqebbs += mlx5e_shampo_icosq_sz(mdev, params, rqp);
+ /* UMR WQEs don't cross the page boundary, they are padded with NOPs.
+ * This padding is always smaller than the max WQE size. That gives us
+ * at least (PAGE_SIZE - (max WQE size - MLX5_SEND_WQE_BB)) useful bytes
+ * per page. The number of pages is estimated as the total size of WQEs
+ * divided by the useful space in page, rounding up. If some WQEs don't
+ * fully fit into the useful space, they can occupy part of the padding,
+ * which proves this estimation to be correct (reserve enough space).
+ */
+ useful_space = PAGE_SIZE - mlx5e_get_max_sq_wqebbs(mdev) + MLX5_SEND_WQE_BB;
+ total_pages = DIV_ROUND_UP(wqebbs * MLX5_SEND_WQE_BB, useful_space);
+ wqebbs = total_pages * (PAGE_SIZE / MLX5_SEND_WQE_BB);
+
return max_t(u8, MLX5E_PARAMS_MINIMUM_LOG_SQ_SIZE, order_base_2(wqebbs));
}
--
2.37.3
next prev parent reply other threads:[~2022-09-29 7:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 7:21 [PATCH net-next 00/16] mlx5 xsk updates part2 2022-09-28 Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 01/16] xsk: Expose min chunk size to drivers Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 02/16] net/mlx5e: Use runtime page_shift for striding RQ Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 03/16] net/mlx5e: xsk: Use XSK frame size as striding RQ page size Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 04/16] net/mlx5e: Keep a separate MKey for striding RQ Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 05/16] net/mlx5: Add MLX5_FLEXIBLE_INLEN to safely calculate cmd inlen Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 06/16] net/mlx5e: xsk: Use KSM for unaligned XSK Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 07/16] xsk: Remove unused xsk_buff_discard Saeed Mahameed
2022-09-29 7:21 ` Saeed Mahameed [this message]
2022-09-29 7:21 ` [PATCH net-next 09/16] net/mlx5e: Optimize the page cache reducing its size 2x Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 10/16] net/mlx5e: Rename mlx5e_dma_info to prepare for removal of DMA address Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 11/16] net/mlx5e: Remove DMA address from mlx5e_alloc_unit Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 12/16] net/mlx5e: Convert struct mlx5e_alloc_unit to a union Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 13/16] net/mlx5e: xsk: Remove mlx5e_xsk_page_alloc_pool Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 14/16] net/mlx5e: Split out channel (de)activation in rx_res Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 15/16] net/mlx5e: Move repeating clear_bit in mlx5e_rx_reporter_err_rq_cqe_recover Saeed Mahameed
2022-09-29 7:21 ` [PATCH net-next 16/16] net/mlx5e: Clean up and fix error flows in mlx5e_alloc_rq Saeed Mahameed
2022-09-29 15:43 ` [PATCH net-next 00/16] mlx5 xsk updates part2 2022-09-28 Jakub Kicinski
2022-09-30 15:50 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220929072156.93299-9-saeed@kernel.org \
--to=saeed@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=maximmi@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).