Subject: Re: XDP multi-buffer design discussion

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 17 Dec 2019 10:00:41 +0100

Jesper Dangaard Brouer <[email-masked]> writes:

> On Mon, 16 Dec 2019 20:15:12 -0800
> Luigi Rizzo <[email-masked]> wrote:
>
>> On Mon, Dec 16, 2019 at 6:07 AM Jesper Dangaard Brouer
>> <[email-masked]> 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" <[email-masked]> 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).

If we want to handle TX and REDIRECT (which I agree we do!), doesn't
that imply that we have to structure the drivers so the XDP program
isn't executed until we have the full packet (i.e., on the last
segment)?

-Toke