Re: XDP multi-buffer design discussion

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Mon, 16 Dec 2019 20:15:12 -0800
Luigi Rizzo <rizzo@iet.unipi.it> wrote:

> On Mon, Dec 16, 2019 at 6:07 AM Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> >
> >
> > See answers inlined below (please get an email client that support
> > inline replies... to interact with this community)
> >
> > On Sun, 15 Dec 2019 13:57:12 +0000
> > "Jubran, Samih" <sameehj@amazon.com> wrote:  
> ...
> > > * Why should we provide the fragments to the bpf program if the
> > > program doesn't access them? If validating the length is what
> > > matters, we can provide only the full length info to the user with no
> > > issues.  
> >
> > My Proposal#1 (in [base-doc]) is that XDP only get access to the
> > first-buffer.  People are welcome to challenge this choice.
> >
> > There are a several sub-questions and challenges hidden inside this
> > choice.
> >
> > As you hint, the total length... spawns some questions we should answer:
> >
> >  (1) is it relevant to the BPF program to know this, explain the use-case.
> >
> >  (2) if so, how does BPF prog access info (without slowdown baseline)  
> 
> For some use cases, the bpf program could deduct the total length
> looking at the L3 header. 

Yes, that actually good insight.  I guess the BPF-program could also
use this to detect that it doesn't have access to the full-lineary
packet this way(?)

> It won't work for XDP_TX response though.

The XDP_TX case also need to be discussed/handled. IMHO need to support
XDP_TX for multi-buffer frames.  XDP_TX *can* be driver specific, but
most drivers choose to convert xdp_buff to xdp_frame, which makes it
possible to use/share part of the XDP_REDIRECT code from ndo_xdp_xmit.

We also need to handle XDP_REDIRECT, which becomes challenging, as the
ndo_xdp_xmit functions of *all* drivers need to be updated (or
introduce a flag to handle this incrementally).


Sameeh, I know you have read the section[1] on "Storage space for
multi-buffer references/segments", and you updated the doc in git-tree.
So, you should understand that I want to keep this compatible with how
SKB stores segments, which will make XDP_PASS a lot easier/faster.
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

[1] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org#storage-space-for-multi-buffer-referencessegments