Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 08, 2025 at 12:10:42PM -0700, Amery Hung wrote:
> On Mon, Sep 8, 2025 at 10:41 AM Paul Chaignon <paul.chaignon@xxxxxxxxx> wrote:
> >
> > 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@xxxxxxxxx> 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.
> 
> Just about to say the same thing Martin mentioned.
> 
> bpf_prog_test_run_xdp() is already using test.ctx_in since
> 47316f4a3053 ("bpf: Support input xdp_md context in
> BPF_PROG_TEST_RUN"). It allows users to supply metadata via
> test.data_in. ctx_in->data_meta must be zero and the first
> ctx_in->data - ctx_in->data_meta bytes in data_in will be copied into
> metadata. So continuing using ctx_in for specifying the linear data
> size is a logical next step.

I didn't know about that. Okay, makes sense. I'll send the v2 using
data_end.

> 
> >
> > >
> > > 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.
> >
> 
> Here is the set I am working on
> https://lore.kernel.org/bpf/20250905173352.3759457-1-ameryhung@xxxxxxxxx/
> 
> Patch 5 allows using ctx_in->data_end to specify the linear xdp_buff
> size (i.e., ctx_in->data_end - ctx_in->data). Patch 6 uses it to test
> a new kfunc, bpf_xdp_pull_data().
> 
> > [...]
> >




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux