netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 03/16] net/mlx5e: xsk: Use XSK frame size as striding RQ page size
Date: Thu, 29 Sep 2022 00:21:43 -0700	[thread overview]
Message-ID: <20220929072156.93299-4-saeed@kernel.org> (raw)
In-Reply-To: <20220929072156.93299-1-saeed@kernel.org>

From: Maxim Mikityanskiy <maximmi@nvidia.com>

XSK RQs support striding RQ linear mode, but the stride size is always
set to PAGE_SIZE. It may be larger than the XSK frame size,
unnecessarily reducing the useful space in a WQE, but more importantly
causing UMEM data corruption in certain cases.

Normally, stride size bigger than XSK frame size is not a problem if the
hardware enforces the MTU. However, traffic between vports skips the
hardware MTU check, and oversized packets may be received.

If an oversized packet is bigger than the XSK frame but not bigger than
the stride, it will cause overwriting of the adjacent UMEM region. If
the packet takes more than one stride, they can be recycled for reuse
so it's not a problem when the XSK frame size matches the stride size.

To reduce the impact of the above issue, attempt to use the MTT page
size for striding RQ that matches the XSK frame size, allowing to safely
use 2048-byte frames on an up-to-date firmware.

Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
 .../ethernet/mellanox/mlx5/core/en/params.c   | 37 ++++++++++++++++---
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
index 1a0d8f9102df..593b684d21d5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
@@ -6,6 +6,7 @@
 #include "en/port.h"
 #include "en_accel/en_accel.h"
 #include "en_accel/ipsec.h"
+#include <net/xdp_sock_drv.h>
 
 static u8 mlx5e_mpwrq_min_page_shift(struct mlx5_core_dev *mdev)
 {
@@ -16,8 +17,8 @@ static u8 mlx5e_mpwrq_min_page_shift(struct mlx5_core_dev *mdev)
 
 u8 mlx5e_mpwrq_page_shift(struct mlx5_core_dev *mdev, struct mlx5e_xsk_param *xsk)
 {
+	u8 req_page_shift = xsk ? order_base_2(xsk->chunk_size) : PAGE_SHIFT;
 	u8 min_page_shift = mlx5e_mpwrq_min_page_shift(mdev);
-	u8 req_page_shift = PAGE_SHIFT;
 
 	/* Regular RQ uses order-0 pages, the NIC must be able to map them. */
 	if (WARN_ON_ONCE(!xsk && req_page_shift < min_page_shift))
@@ -933,12 +934,36 @@ static u8 mlx5e_build_icosq_log_wq_sz(struct mlx5_core_dev *mdev,
 	/* If XDP program is attached, XSK may be turned on at any time without
 	 * restarting the channel. ICOSQ must be big enough to fit UMR WQEs of
 	 * both regular RQ and XSK RQ.
-	 * Although mlx5e_mpwqe_get_log_rq_size accepts mlx5e_xsk_param, it
-	 * doesn't affect its return value, as long as params->xdp_prog != NULL,
-	 * so we can just multiply by 2.
+	 *
+	 * XSK uses different values of page_shift, and the total number of UMR
+	 * WQEBBs depends on it. This dependency is complex and not monotonic,
+	 * especially taking into consideration that some of the parameters come
+	 * from capabilities. Hence, we have to try all valid values of XSK
+	 * frame size (and page_shift) to find the maximum.
 	 */
-	if (params->xdp_prog)
-		wqebbs *= 2;
+	if (params->xdp_prog) {
+		u32 max_xsk_wqebbs = 0;
+		u8 frame_shift;
+
+		for (frame_shift = XDP_UMEM_MIN_CHUNK_SHIFT;
+		     frame_shift <= PAGE_SHIFT; frame_shift++) {
+			/* The headroom doesn't affect the calculation. */
+			struct mlx5e_xsk_param xsk = {
+				.chunk_size = 1 << frame_shift,
+			};
+			u32 xsk_wqebbs;
+			u8 page_shift;
+
+			page_shift = mlx5e_mpwrq_page_shift(mdev, &xsk);
+			xsk_wqebbs = mlx5e_mpwrq_umr_wqebbs(mdev, page_shift) *
+				(1 << mlx5e_mpwqe_get_log_rq_size(mdev, params, &xsk));
+
+			if (xsk_wqebbs > max_xsk_wqebbs)
+				max_xsk_wqebbs = xsk_wqebbs;
+		}
+
+		wqebbs += max_xsk_wqebbs;
+	}
 
 	if (params->packet_merge.type == MLX5E_PACKET_MERGE_SHAMPO)
 		wqebbs += mlx5e_shampo_icosq_sz(mdev, params, rqp);
-- 
2.37.3


  parent reply	other threads:[~2022-09-29  7:22 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 ` Saeed Mahameed [this message]
2022-09-29  7:21 ` [PATCH net-next 04/16] net/mlx5e: Keep a separate MKey " 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 ` [PATCH net-next 08/16] net/mlx5e: Fix calculations for ICOSQ size Saeed Mahameed
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-4-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).