From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Tariq Toukan <ttoukan.linux@gmail.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "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>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Network Development <netdev@vger.kernel.org>,
linux-rdma@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
bpf <bpf@vger.kernel.org>, Moshe Shemesh <moshe@nvidia.com>,
Mark Bloch <mbloch@nvidia.com>, Gal Pressman <gal@nvidia.com>,
Carolina Jubran <cjubran@nvidia.com>,
Sebastiano Miano <mianosebastiano@gmail.com>,
Samuel Dobron <sdobron@redhat.com>
Subject: Re: [PATCH net-next] net/mlx5e: Reuse per-RQ XDP buffer to avoid stack zeroing overhead
Date: Fri, 16 May 2025 16:43:54 +0200 [thread overview]
Message-ID: <09377c1a-dac5-487d-9fc1-d973b20b04dd@kernel.org> (raw)
In-Reply-To: <dcb3053f-6588-4c87-be42-a172dacb1828@gmail.com>
On 16/05/2025 15.47, Tariq Toukan wrote:
>
>
> On 15/05/2025 3:26, Alexei Starovoitov wrote:
>> On Wed, May 14, 2025 at 1:04 PM Tariq Toukan <tariqt@nvidia.com> wrote:
>>>
>>> From: Carolina Jubran <cjubran@nvidia.com>
>>>
>>> CONFIG_INIT_STACK_ALL_ZERO introduces a performance cost by
>>> zero-initializing all stack variables on function entry. The mlx5 XDP
>>> RX path previously allocated a struct mlx5e_xdp_buff on the stack per
>>> received CQE, resulting in measurable performance degradation under
>>> this config.
>>>
>>> This patch reuses a mlx5e_xdp_buff stored in the mlx5e_rq struct,
>>> avoiding per-CQE stack allocations and repeated zeroing.
>>>
>>> With this change, XDP_DROP and XDP_TX performance matches that of
>>> kernels built without CONFIG_INIT_STACK_ALL_ZERO.
>>>
>>> Performance was measured on a ConnectX-6Dx using a single RX channel
>>> (1 CPU at 100% usage) at ~50 Mpps. The baseline results were taken from
>>> net-next-6.15.
>>>
>>> Stack zeroing disabled:
>>> - XDP_DROP:
>>> * baseline: 31.47 Mpps
>>> * baseline + per-RQ allocation: 32.31 Mpps (+2.68%)
>>>
31.47 Mpps = 31.77 nanosec per packet
32.31 Mpps = 30.95 nanosec per packet
Improvement: 0.82 nanosec faster
>>> - XDP_TX:
>>> * baseline: 12.41 Mpps
>>> * baseline + per-RQ allocation: 12.95 Mpps (+4.30%)
>>
The XDP_TX number are actually lower than I expected.
Hmm... I wonder if we regressed here(?)
12.41 Mpps = 80.58 nanosec per packet
12.95 Mpps = 77.22 nanosec per packet
Improvement: 3.36 nanosec faster
>> Looks good, but where are these gains coming from ?
>> The patch just moves mxbuf from stack to rq.
>> The number of operations should really be the same.
>>
>
> I guess it's cache related. Hot/cold areas, alignments, movement of
> other fields in the mlx5e_rq structure...
The improvements for XDP_DROP (see calc above) in nanosec is so small
that it is hard to measure accurately/stable on any system.
The improvement for XDP_TX is above 2 nanosec, which looks like an
actual improvement...
>>> Stack zeroing enabled:
>>> - XDP_DROP:
>>> * baseline: 24.32 Mpps
>>> * baseline + per-RQ allocation: 32.27 Mpps (+32.7%)
>>
>> This part makes sense.
>
Yes, this makes sense as it is a measurable improvement.
24.32 Mpps = 41.12 nanosec per packet
32.27 Mpps = 30.99 nanosec per packet
Improvement: 10.13 nanosec faster
Acked-by: Jesper Dangaard Brouer <hawk@kernel.org>
--Jesper
next prev parent reply other threads:[~2025-05-16 14:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 20:03 Tariq Toukan
2025-05-15 0:26 ` Alexei Starovoitov
2025-05-16 13:47 ` Tariq Toukan
2025-05-16 14:43 ` Jesper Dangaard Brouer [this message]
2025-05-21 8:56 ` Samuel Dobron
2025-05-16 22: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=09377c1a-dac5-487d-9fc1-d973b20b04dd@kernel.org \
--to=hawk@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cjubran@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gal@nvidia.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=mbloch@nvidia.com \
--cc=mianosebastiano@gmail.com \
--cc=moshe@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=sdobron@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®