From: Marcus Wichelmann <marcus.wichelmann@hetzner-cloud.de>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: jasowang@redhat.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, mykolal@fb.com, shuah@kernel.org,
hawk@kernel.org
Subject: Re: [PATCH bpf-next v2 2/6] net: tun: enable transfer of XDP metadata to skb
Date: Wed, 19 Feb 2025 15:47:09 +0100 [thread overview]
Message-ID: <dee9bc39-e666-4d97-8a42-240ffb458bcc@hetzner-cloud.de> (raw)
In-Reply-To: <67b3e6b6b9dc6_c0e2529482@willemb.c.googlers.com.notmuch>
Am 18.02.25 um 02:47 schrieb Willem de Bruijn:
> Marcus Wichelmann wrote:
>> [...]
>> + metasize = max(xdp->data - xdp->data_meta, 0);
>
> Can xdp->data_meta ever be greater than xdp->data?
When an xdp_buff has no metadata support, then this is marked by setting
xdp->data_meta to xdp->data + 1. See xdp_prepare_buff or
xdp_set_data_meta_invalid.
In the case of tun_xdp_one, the xdp_buff is externally created by another
driver and passed to the tun driver using sendmsg and TUN_MSG_PTR. For
now, the vhost_net driver is the only driver doing that, and
xdp->data_meta is set to xdp->data there, marking support for metadata.
So knowing that vhost_net is currently the only driver passing xdp_buffs
to tun_sendmsg, the check is not strictly necessary. But other drivers
may use this API as well in the future. That's why I'd like to not make
the assumption that other drivers always create the xdp_buffs with
metadata support, when they pass them to tun_sendmsg.
Or am I just to careful about this? What do you think?
> This is pointer comparison, which is tricky wrt type. It likely is
> ptrdiff_t and thus signed. But may want to use max_t(long int, ..) to
> make this explicit.
Ah, I see, good point.
So like that?
metasize = max_t(long int, xdp->data - xdp->data_meta, 0);
if (metasize)
skb_metadata_set(skb, metasize);
Alternatively, there is also xdp_data_meta_unsupported(xdp_buff) which
could be used to make this check very explicit, but I don't see it being
used in network drivers elsewhere. Not sure why.
>> + if (metasize)
>> + skb_metadata_set(skb, metasize);
>> +
>
> Not strictly needed. As skb_metadata_clear is just
> skb_metadata_set(skb, 0). But also not wrong, so fine to keep.
Oh, haven't seen that.
I'm following a common pattern here that I've seen in many other network
drivers (grep for "skb_metadata_set"):
unsigned int metasize = xdp->data - xdp->data_meta;
[...]
if (metasize)
skb_metadata_set(skb, metasize);
Marcus
next prev parent reply other threads:[~2025-02-19 14:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 17:23 [PATCH bpf-next v2 0/6] XDP metadata support for tun driver Marcus Wichelmann
2025-02-17 17:23 ` [PATCH bpf-next v2 1/6] net: tun: enable XDP metadata support Marcus Wichelmann
2025-02-19 3:17 ` Jason Wang
2025-02-17 17:23 ` [PATCH bpf-next v2 2/6] net: tun: enable transfer of XDP metadata to skb Marcus Wichelmann
2025-02-18 1:45 ` Willem de Bruijn
2025-02-18 1:47 ` Willem de Bruijn
2025-02-19 14:47 ` Marcus Wichelmann [this message]
2025-02-19 15:06 ` Willem de Bruijn
2025-02-19 15:15 ` Marcus Wichelmann
2025-02-17 17:23 ` [PATCH bpf-next v2 3/6] selftests/bpf: move open_tuntap to network helpers Marcus Wichelmann
2025-02-18 1:50 ` Willem de Bruijn
2025-02-17 17:23 ` [PATCH bpf-next v2 4/6] selftests/bpf: refactor xdp_context_functional test and bpf program Marcus Wichelmann
2025-02-17 17:23 ` [PATCH bpf-next v2 5/6] selftests/bpf: add test for XDP metadata support in tun driver Marcus Wichelmann
2025-02-17 17:23 ` [PATCH bpf-next v2 6/6] selftests/bpf: fix file descriptor assertion in open_tuntap helper Marcus Wichelmann
2025-02-18 1:56 ` Willem de Bruijn
2025-02-19 14:58 ` Marcus Wichelmann
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=dee9bc39-e666-4d97-8a42-240ffb458bcc@hetzner-cloud.de \
--to=marcus.wichelmann@hetzner-cloud.de \
--cc=andrew+netdev@lunn.ch \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=jasowang@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=yonghong.song@linux.dev \
/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).