llvm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Nimrod Oren <noren@nvidia.com>
Cc: Mohsin Bashir <mohsin.bashr@gmail.com>,
	netdev@vger.kernel.org, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	shuah@kernel.org, horms@kernel.org, cratiu@nvidia.com,
	cjubran@nvidia.com, mbloch@nvidia.com, jdamato@fastly.com,
	gal@nvidia.com, sdf@fomichev.me, ast@kernel.org,
	daniel@iogearbox.net, hawk@kernel.org, john.fastabend@gmail.com,
	nathan@kernel.org, nick.desaulniers+lkml@gmail.com,
	morbo@google.com, justinstitt@google.com, bpf@vger.kernel.org,
	linux-kselftest@vger.kernel.org, llvm@lists.linux.dev,
	tariqt@nvidia.com, thoiland@redhat.com
Subject: Re: [PATCH net-next V6 2/5] selftests: drv-net: Test XDP_PASS/DROP support
Date: Mon, 21 Jul 2025 08:40:46 -0700	[thread overview]
Message-ID: <20250721084046.5659971c@kernel.org> (raw)
In-Reply-To: <ab65545f-c79c-492b-a699-39f7afa984ea@nvidia.com>

On Mon, 21 Jul 2025 14:43:15 +0300 Nimrod Oren wrote:
> > +static struct udphdr *filter_udphdr(struct xdp_md *ctx, __u16 port)
> > +{
> > +	void *data_end = (void *)(long)ctx->data_end;
> > +	void *data = (void *)(long)ctx->data;
> > +	struct udphdr *udph = NULL;
> > +	struct ethhdr *eth = data;
> > +
> > +	if (data + sizeof(*eth) > data_end)
> > +		return NULL;
> > +  
> 
> This check assumes that the packet headers reside in the linear part of
> the xdp_buff. However, this assumption does not hold across all drivers.
> For example, in mlx5, the linear part is empty when using multi-buffer
> mode with striding rq configuration. This causes all multi-buffer test
> cases to fail over mlx5.
> 
> To ensure correctness across all drivers, all direct accesses to packet
> data should use these safer helper functions instead:
> bpf_xdp_load_bytes() and bpf_xdp_store_bytes().
> 
> Related discussion and context can be found here:
> https://github.com/xdp-project/xdp-tools/pull/409

That's a reasonable way to modify the test. But I'm not sure it's
something that should be blocking merging the patches.
Or for that matter whether it's Mohsin's responsibility to make the
test cater to quirks of mlx5, which is not even part of NIPA testing -
we have no way of knowing what passes for mlx5, what regresses it etc.

Not related to this series, but I'd be curious what the perf hit is for
having to load the headers.

  reply	other threads:[~2025-07-21 15:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-19  8:30 [PATCH net-next V6 0/5] selftests: drv-net: Test XDP native support Mohsin Bashir
2025-07-19  8:30 ` [PATCH net-next V6 1/5] net: netdevsim: hook in XDP handling Mohsin Bashir
2025-07-19  8:30 ` [PATCH net-next V6 2/5] selftests: drv-net: Test XDP_PASS/DROP support Mohsin Bashir
2025-07-21 11:43   ` Nimrod Oren
2025-07-21 15:40     ` Jakub Kicinski [this message]
2025-07-21 18:34       ` Gal Pressman
2025-07-21 20:33         ` Jakub Kicinski
2025-07-22  7:21           ` Gal Pressman
2025-07-22 13:49             ` Jakub Kicinski
2025-07-22 15:03         ` Paolo Abeni
2025-07-23  6:17           ` Gal Pressman
2025-07-21 19:43     ` Martin KaFai Lau
2025-07-21 20:24       ` Jakub Kicinski
2025-07-19  8:30 ` [PATCH net-next V6 3/5] selftests: drv-net: Test XDP_TX support Mohsin Bashir
2025-07-19  8:30 ` [PATCH net-next V6 4/5] selftests: drv-net: Test tail-adjustment support Mohsin Bashir
2025-07-19  8:30 ` [PATCH net-next V6 5/5] selftests: drv-net: Test head-adjustment support Mohsin Bashir
2025-07-23  1:30 ` [PATCH net-next V6 0/5] selftests: drv-net: Test XDP native support patchwork-bot+netdevbpf
2025-07-23  7:11   ` Gal Pressman
2025-07-23 14:12     ` Jakub Kicinski
2025-07-23 16:01       ` Gal Pressman
2025-07-24  9:05         ` Simon Horman

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=20250721084046.5659971c@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cjubran@nvidia.com \
    --cc=cratiu@nvidia.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=jdamato@fastly.com \
    --cc=john.fastabend@gmail.com \
    --cc=justinstitt@google.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mbloch@nvidia.com \
    --cc=mohsin.bashr@gmail.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=noren@nvidia.com \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=tariqt@nvidia.com \
    --cc=thoiland@redhat.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).