From: Jakub Kicinski <kuba@kernel.org>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
lorenzo@kernel.org, pabeni@redhat.com, bpf@vger.kernel.org,
hawk@kernel.org, toke@redhat.com
Subject: Re: [PATCH net-next] xdp: add multi-buff support for xdp running in generic mode
Date: Tue, 28 Nov 2023 10:51:45 -0800 [thread overview]
Message-ID: <20231128105145.7b39db7d@kernel.org> (raw)
In-Reply-To: <ZWYjcNlo7RAX8M0T@lore-desk>
On Tue, 28 Nov 2023 18:29:20 +0100 Lorenzo Bianconi wrote:
> @Jakub: iirc we were discussing something similar for veth [0].
> Here pskb_expand_head() reallocates skb paged data (skb_shinfo()->frags[])
> just if the skb is cloned and if it is zero-copied [1] while in skb_cow_data()
> we always reallocate the paged area if skb_shinfo()->nr_frags is set [2].
> Since the eBPF program can theoretically modify paged data, I would say we
> should do the same we did for veth even here, right?
Yes, don't we allow writes to fragments in XDP based on the assumption
that it runs on Rx so that paged data must not be zero copy?
bpf_xdp_store_bytes() doesn't seem to have any checks which would
stop it from writing fragments, as far as I can see.
I don't see how we can ever correctly support this form of mbuf for veth
or generic XDP :(
next prev parent reply other threads:[~2023-11-28 18:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 23:38 [PATCH net-next] xdp: add multi-buff support for xdp running in generic mode Lorenzo Bianconi
2023-11-28 9:45 ` Toke Høiland-Jørgensen
2023-11-28 12:02 ` Lorenzo Bianconi
2023-11-28 17:29 ` Lorenzo Bianconi
2023-11-28 18:51 ` Jakub Kicinski [this message]
2023-11-28 22:27 ` Lorenzo Bianconi
2023-11-28 23:10 ` Jakub Kicinski
2023-11-29 16:36 ` Lorenzo Bianconi
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=20231128105145.7b39db7d@kernel.org \
--to=kuba@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=toke@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).