On Wed, Sep 29, 2021 at 5:38 AM Lorenz Bauer <lmb@xxxxxxxxxxxxxx> wrote:
>
> On Wed, 29 Sept 2021 at 13:10, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> >
> > Lorenz Bauer <lmb@xxxxxxxxxxxxxx> writes:
> >
> > > On Thu, 16 Sept 2021 at 18:47, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
> > >>
> > >> Won't applications end up building something like skb_header_pointer()
> > >> based on bpf_xdp_adjust_data(), anyway? In which case why don't we
> > >> provide them what they need?
> > >>
> > >> say:
> > >>
> > >> void *xdp_mb_pointer(struct xdp_buff *xdp_md, u32 flags,
> > >> u32 offset, u32 len, void *stack_buf)
> > >>
> > >> flags and offset can be squashed into one u64 as needed. Helper returns
> > >> pointer to packet data, either real one or stack_buf. Verifier has to
> > >> be taught that the return value is NULL or a pointer which is safe with
> > >> offsets up to @len.
> > >>
> > >> If the reason for access is write we'd also need:
> > >>
> > >> void *xdp_mb_pointer_flush(struct xdp_buff *xdp_md, u32 flags,
> > >> u32 offset, u32 len, void *stack_buf)
I'm missing something. Why do we need a separate flush() helper?
Can't we do:
char buf[64], *p;
p = xdp_mb_pointer(ctx, flags, off, len, buf);
read/write p[]
if (p == buf)
xdp_store_bytes(ctx, off, buf, len, flags);
