From: Dragos Tatulea <dtatulea@nvidia.com>
To: Tariq Toukan <tariqt@nvidia.com>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Mark Bloch <mbloch@nvidia.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Cosmin Ratiu <cratiu@nvidia.com>,
Simon Horman <horms@kernel.org>,
Jacob Keller <jacob.e.keller@intel.com>,
Lama Kayal <lkayal@nvidia.com>,
Michal Swiatkowski <michal.swiatkowski@linux.intel.com>,
Carolina Jubran <cjubran@nvidia.com>,
Nathan Chancellor <nathan@kernel.org>,
Daniel Zahka <daniel.zahka@gmail.com>,
Rahul Rameshbabu <rrameshbabu@nvidia.com>,
Raed Salem <raeds@nvidia.com>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
Gal Pressman <gal@nvidia.com>
Subject: Re: [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq
Date: Sun, 5 Apr 2026 08:08:06 +0200 [thread overview]
Message-ID: <adH5yAsPJ8rNgT0k@x13> (raw)
In-Reply-To: <20260403090927.139042-5-tariqt@nvidia.com>
On Fri, Apr 03, 2026 at 12:09:26PM +0300, Tariq Toukan wrote:
> From: Dragos Tatulea <dtatulea@nvidia.com>
>
> Currently in striding rq there is one mlx5e_frag_page member per WQE for
> the linear page. This linear page is used only in XDP multi-buffer mode.
> This is wasteful because only one linear page is needed per rq: the page
> gets refreshed on every packet, regardless of WQE. Furthermore, it is
> not needed in other modes (non-XDP, XDP single-buffer).
>
> This change moves the linear page into its own structure (struct
> mlx5_mpw_linear_info) and allocates it only when necessary.
>
> A special structure is created because an upcoming patch will extend
> this structure to support fragmentation of the linear page.
>
> This patch has no functional changes.
>
> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 6 ++-
>
> [...]
> +static int mlx5e_rq_alloc_mpwqe_linear_info(struct mlx5e_rq *rq, int node,
> + struct mlx5e_params *params,
> + struct mlx5e_rq_opt_param *rqo,
> + u32 *pool_size)
> +{
> + struct mlx5_core_dev *mdev = rq->mdev;
> + struct mlx5e_mpw_linear_info *li;
> +
> + if (mlx5e_rx_mpwqe_is_linear_skb(mdev, params, rqo) ||
> + !params->xdp_prog)
> + return 0;
> +
sashiko says:
"""
Could mlx5e_rx_mpwqe_is_linear_skb() return true here (meaning li is not
allocated), but later return false when the rx handlers are being set up?
When mlx5e_open_rq() sets up handlers it passes NULL for rqo to
mlx5e_rx_mpwqe_is_linear_skb(). Inside that function, without rqo, the
page_shift calculation falls back to the system PAGE_SHIFT rather than
rqo->qcfg->rx_page_size. A smaller page_shift could cause the stride check
to fail, returning false.
If the allocation evaluates to true (skipping allocation) but the handler setup
evaluates to false, the nonlinear handler mlx5e_skb_from_cqe_mpwrq_nonlinear
will be used for the queue.
"""
This is by design. HW-GRO is the mode that Sashiko is talking about. In
that mode linear_info is not used hence not allocated.
> [...]
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
> @@ -1869,6 +1869,7 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
> struct mlx5e_frag_page *frag_page = &wi->alloc_units.frag_pages[page_idx];
> u16 headlen = min_t(u16, MLX5E_RX_MAX_HEAD, cqe_bcnt);
> struct mlx5e_frag_page *head_page = frag_page;
> + struct mlx5e_frag_page *linear_page = NULL;
> struct mlx5e_xdp_buff *mxbuf = &rq->mxbuf;
> u32 page_size = BIT(rq->mpwqe.page_shift);
> u32 frag_offset = head_offset;
> @@ -1897,13 +1898,15 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
> if (prog) {
> /* area for bpf_xdp_[store|load]_bytes */
> net_prefetchw(netmem_address(frag_page->netmem) + frag_offset);
> +
> + linear_page = &rq->mpwqe.linear_info->frag_page;
"""
If mlx5e_skb_from_cqe_mpwrq_nonlinear() is invoked but linear_info was skipped
during allocation, does this result in a NULL pointer dereference when accessing
linear_info->frag_page?
"""
Connected to the statement above. linear_page will always be allocated
for this handler.
[1] https://sashiko.dev/#/patchset/20260403090927.139042-1-tariqt%40nvidia.com?part=4
Thanks,
Dragos
next prev parent reply other threads:[~2026-04-05 6:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 9:09 [PATCH net-next V2 0/5] net/mlx5e: XDP, Add support for multi-packet per page Tariq Toukan
2026-04-03 9:09 ` [PATCH net-next V2 1/5] net/mlx5e: XSK, Increase size for chunk_size param Tariq Toukan
2026-04-05 6:30 ` Dragos Tatulea
2026-04-03 9:09 ` [PATCH net-next V2 2/5] net/mlx5e: XDP, Improve dma address calculation of linear part for XDP_TX Tariq Toukan
2026-04-03 9:09 ` [PATCH net-next V2 3/5] net/mlx5e: XDP, Remove stride size limitation Tariq Toukan
2026-04-03 9:09 ` [PATCH net-next V2 4/5] net/mlx5e: XDP, Use a single linear page per rq Tariq Toukan
2026-04-05 6:08 ` Dragos Tatulea [this message]
2026-04-06 15:43 ` Jakub Kicinski
2026-04-06 16:31 ` Mark Bloch
2026-04-06 18:30 ` Jakub Kicinski
2026-04-06 19:50 ` Mark Bloch
2026-04-06 19:13 ` Nicolai Buchwitz
2026-04-06 19:52 ` Mark Bloch
2026-04-07 0:43 ` Jakub Kicinski
2026-04-03 9:09 ` [PATCH net-next V2 5/5] net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode Tariq Toukan
2026-04-07 11:50 ` [PATCH net-next V2 0/5] net/mlx5e: XDP, Add support for multi-packet per page 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=adH5yAsPJ8rNgT0k@x13 \
--to=dtatulea@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cjubran@nvidia.com \
--cc=cratiu@nvidia.com \
--cc=daniel.zahka@gmail.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lkayal@nvidia.com \
--cc=mbloch@nvidia.com \
--cc=michal.swiatkowski@linux.intel.com \
--cc=nathan@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raeds@nvidia.com \
--cc=rrameshbabu@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--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