From: Paul Chaignon <paul.chaignon@gmail.com>
To: Amery Hung <ameryhung@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>
Subject: Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
Date: Mon, 8 Sep 2025 19:41:48 +0200 [thread overview]
Message-ID: <aL8VXGQASeRo92xz@Tunnel> (raw)
In-Reply-To: <CAMB2axML8WkmA2Bv3gtvTnyq75cDO8ctqnPetB0jsYLQZVmNyg@mail.gmail.com>
On Fri, Sep 05, 2025 at 09:34:54AM -0700, Amery Hung wrote:
> On Fri, Sep 5, 2025 at 6:24 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> >
> > On Thu, Sep 04, 2025 at 09:27:58AM -0700, Amery Hung wrote:
[...]
> > > How about letting users specify the linear size through ctx->data_end? I am
> > > working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
> > > to support non-linear xdp_buff in test_run_xdp, and I am doing it through
> > > ctx->data_end. Is it something reasonable for test_run_skb?
> >
> > Oh, nice! That was next on my list :)
> >
> > Why use data_end though? I guess it'd work for skb, but can't we just
> > add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
> >
>
> I choose to use ctx_in because it doesn't change the interface and
> feels natural. kattr->test.ctx_in is already copied from users and
> shows users' expectation about the input ctx. I think we should honor
> that (as long as the value makes sense). WDYT?
Ok, I think I see your point of view. To me, test.ctx_in *is* the
context and not metadata about it. I'm worried it would be weird to
users if we overload that field. I'm not against using that though if
it's the consensus.
>
> Thanks for working on this. It would be great if there is some
> consistency between test_run_skb and test_run_xdp.
Definitely agree! Do you have a prototype anywhere I could check? If
not, you can always flag any inconsistency when I send the v2.
[...]
next prev parent reply other threads:[~2025-09-08 17:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
2025-09-04 12:09 ` [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb Paul Chaignon
2025-09-05 12:57 ` kernel test robot
2025-09-04 12:11 ` [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN Paul Chaignon
2025-09-04 15:56 ` Alexei Starovoitov
2025-09-04 16:02 ` Daniel Borkmann
2025-09-04 16:27 ` Amery Hung
2025-09-05 13:23 ` Paul Chaignon
2025-09-05 16:34 ` Amery Hung
2025-09-08 17:41 ` Paul Chaignon [this message]
2025-09-08 19:09 ` Martin KaFai Lau
2025-09-08 19:10 ` Amery Hung
2025-09-08 19:16 ` Paul Chaignon
2025-09-04 12:13 ` [PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader Paul Chaignon
2025-09-04 12:13 ` [PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs Paul Chaignon
2025-09-04 18:08 ` [syzbot ci] Re: bpf: Support non-linear skbs for BPF_PROG_TEST_RUN syzbot ci
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=aL8VXGQASeRo92xz@Tunnel \
--to=paul.chaignon@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.