On Tue, Jan 31, 2023 at 12:48 PM Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
> > > >
> > > > p = bpf_dynptr_slice(dp, off, 16, buf);
> > > > if (p == NULL) {
> > > > /* out of range */
> > > > } else {
> > > > /* work with p directly */
> > > > }
> > > >
> > > > /* if we wrote something to p and it was copied to buffer, write it back */
> > > > if (p == buf) {
> > > > bpf_dynptr_write(dp, buf, 16);
> > > > }
> > > >
> > > >
> > > > We'll just need to teach verifier to make sure that buf is at least 16
> > > > byte long.
> > >
> > > I'm confused what the benefit of passing in the buffer is. If it's to
> > > avoid the uncloning, this will still need to happen if the user writes
> > > back the data to the skb (which will be the majority of cases). If
> > > it's to avoid uncloning if the user only reads the data of a writable
> > > prog, then we could add logic in the verifier so that we don't pull
> > > the data in this case; the uncloning might still happen regardless if
> > > another part of the program does a direct write. If the benefit is to
> > > avoid needing to pull the data, then can't the user just use
> > > bpf_dynptr_read, which takes in a buffer?
> >
> > There is no unclone and there is no pull in xdp.
> > The main idea of this semantics of bpf_dynptr_slice is to make it
> > work the same way on skb and xdp for _read_ case.
> > Writes are going to be different between skb and xdp anyway.
> > In some rare cases the writes can be the same for skb and xdp
> > with this bpf_dynptr_slice + bpf_dynptr_write logic,
> > but that's a minor feature addition of the api.
>
> bpf_dynptr_read works the same way on skb and xdp. bpf_dynptr_read
> takes in a buffer as well, so what is the added benefit of
> bpf_dynptr_slice?
That it doesn't copy most of the time.
