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) > > > > Yes! This would be so much better than bpf_skb_load/store_bytes(), > > especially if we can use it for both XDP and skb contexts as stated > > elsewhere in this thread. > > Alright. Let's see if we can go this route, then :) Something I forgot to mention: you could infer that an XDP program is mb-aware if it only does packet access via the helpers. Put another way, it might be nice if ctx->data wasn't accessible in mb XDP. That way I know that all packet access has to handle mb-aware ctx (think pulling in functions via headers or even pre-compiled bpf libraries). -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com
