From: Simon Horman <horms@kernel.org>
To: Tariq Toukan <ttoukan.linux@gmail.com>
Cc: Tariq Toukan <tariqt@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Gal Pressman <gal@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, Moshe Shemesh <moshe@nvidia.com>,
Mark Bloch <mbloch@nvidia.com>, Lama Kayal <lkayal@nvidia.com>
Subject: Re: [PATCH net] net/mlx5e: SHAMPO, Make reserved size independent of page size
Date: Mon, 31 Mar 2025 10:46:20 +0100 [thread overview]
Message-ID: <20250331094620.GA185681@horms.kernel.org> (raw)
In-Reply-To: <ea6a499b-c267-4fa3-8ed6-983ab96b3b9e@gmail.com>
On Thu, Mar 27, 2025 at 07:58:30PM +0200, Tariq Toukan wrote:
>
>
> On 25/03/2025 16:04, Simon Horman wrote:
> > On Sun, Mar 23, 2025 at 02:28:26PM +0200, Tariq Toukan wrote:
> > > From: Lama Kayal <lkayal@nvidia.com>
> > >
> > > When hw-gro is enabled, the maximum number of header entries that are
> > > needed per wqe (hd_per_wqe) is calculated based on the size of the
> > > reservations among other parameters.
> > >
> > > Miscalculation of the size of reservations leads to incorrect
> > > calculation of hd_per_wqe as 0, particularly in the case of large page
> > > size like in aarch64, this prevents the SHAMPO header from being
> > > correctly initialized in the device, ultimately causing the following
> > > cqe err that indicates a violation of PD.
> >
> > Hi Lama, Tariq, all,
> >
> > If I understand things correctly, hd_per_wqe is calculated
> > in mlx5e_shampo_hd_per_wqe() like this:
> >
> > u32 mlx5e_shampo_hd_per_wqe(struct mlx5_core_dev *mdev,
> > struct mlx5e_params *params, struct mlx5e_rq_param *rq_param)
> > {
> > int resv_size = BIT(mlx5e_shampo_get_log_rsrv_size(mdev, params)) * PAGE_SIZE;
> > u16 num_strides = BIT(mlx5e_mpwqe_get_log_num_strides(mdev, params, NULL));
> > int pkt_per_resv = BIT(mlx5e_shampo_get_log_pkt_per_rsrv(mdev, params));
> > u8 log_stride_sz = mlx5e_mpwqe_get_log_stride_size(mdev, params, NULL);
> > int wqe_size = BIT(log_stride_sz) * num_strides; u32 hd_per_wqe;
> >
> > /* Assumption: hd_per_wqe % 8 == 0. */
> > hd_per_wqe = (wqe_size / resv_size) * pkt_per_resv; mlx5_core_dbg(mdev, "%s hd_per_wqe = %d rsrv_size = %d wqe_size = %d pkt_per_resv = %d\n", __func__, hd_per_wqe, resv_size, wqe_size, pkt_per_resv);
> > return hd_per_wqe;
> > }
> >
> > I can see that if PAGE_SIZE was some multiple of 4k, and thus
> > larger than wqe_size, then this could lead to hd_per_wqe being zero.
> >
> > But I note that mlx5e_mpwqe_get_log_stride_size() may return PAGE_SHIFT.
> > And I wonder if that leads to wqe_size being larger than expected by this
> > patch in cases where the PAGE_SIZE is greater than 4k.
> >
> > Likewise in mlx5e_shampo_get_log_cq_size(), which seems to have a large overlap
> > codewise with mlx5e_shampo_hd_per_wqe().
> >
> > >
>
> Hi Simon,
>
> Different settings lead to different combinations of num_strides and
> stride_size. However, they affect each other in a way that the resulting
> wqe_size has the expected (~preset) value.
>
> In mlx5e_mpwqe_get_log_num_strides() you can see that if stride_size grows,
> then num_strides decreases accordingly.
>
> In addition, to reduce mistakes/bugs, we have a few WARNs() along the
> calculations, in addition to a verifier function
> mlx5e_verify_rx_mpwqe_strides().
Hi Tariq,
Sorry for the slow response, I was AFK for a few days.
Thanks for confirming that this is as expected.
next prev parent reply other threads:[~2025-03-31 9:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-23 12:28 [PATCH net] net/mlx5e: SHAMPO, Make reserved size independent of page size Tariq Toukan
2025-03-25 14:04 ` Simon Horman
2025-03-27 17:58 ` Tariq Toukan
2025-03-31 9:46 ` Simon Horman [this message]
2025-03-28 13: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=20250331094620.GA185681@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lkayal@nvidia.com \
--cc=mbloch@nvidia.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
--cc=ttoukan.linux@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.