From: "Toke Høiland-Jørgensen" <toke@redhat•com>
To: Jesper Dangaard Brouer <brouer@redhat•com>,
Luigi Rizzo <rizzo@iet•unipi.it>
Cc: "Jubran\, Samih" <sameehj@amazon•com>, "Machulsky\,
Zorik" <zorik@amazon•com>,
Daniel Borkmann <borkmann@iogearbox•net>,
David Miller <davem@davemloft•net>, "Tzalik\,
Guy" <gtzalik@amazon•com>,
Ilias Apalodimas <ilias.apalodimas@linaro•org>, "Kiyanovski\,
Arthur" <akiyano@amazon•com>, Alexei Starovoitov <ast@kernel•org>,
"netdev\@vger.kernel.org" <netdev@vger•kernel.org>,
David Ahern <dsahern@gmail•com>,
brouer@redhat•com
Subject: Re: XDP multi-buffer design discussion
Date: Tue, 17 Dec 2019 10:00:41 +0100 [thread overview]
Message-ID: <87eex38gxy.fsf@toke.dk> (raw)
In-Reply-To: <20191217094635.7e4cac1c@carbon>
Jesper Dangaard Brouer <brouer@redhat•com> writes:
> 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).
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
next prev parent reply other threads:[~2019-12-17 9:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BA8DC06A-C508-402D-8A18-B715FBA674A2@amazon.com>
[not found] ` <b28504a3-4a55-d302-91fe-63915e4568d3@iogearbox.net>
[not found] ` <5FA3F980-29E6-4B91-8150-9F28C0E09C45@amazon.com>
[not found] ` <20190823084704.075aeebd@carbon>
[not found] ` <67C7F66A-A3F7-408F-9C9E-C53982BCCD40@amazon.com>
[not found] ` <20191204155509.6b517f75@carbon>
[not found] ` <ec2fd7f6da44410fbaeb021cf984f2f6@EX13D11EUC003.ant.amazon.com>
2019-12-16 14:07 ` XDP multi-buffer design discussion Jesper Dangaard Brouer
2019-12-17 4:15 ` Luigi Rizzo
2019-12-17 8:46 ` Jesper Dangaard Brouer
2019-12-17 9:00 ` Toke Høiland-Jørgensen [this message]
2019-12-17 15:44 ` Jubran, Samih
2019-12-17 22:30 ` Luigi Rizzo
2019-12-18 16:03 ` Jubran, Samih
2019-12-19 10:44 ` Jesper Dangaard Brouer
2019-12-19 17:29 ` Luigi Rizzo
2020-01-19 7:34 ` Jubran, Samih
2020-01-22 18:50 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eex38gxy.fsf@toke.dk \
--to=toke@redhat$(echo .)com \
--cc=akiyano@amazon$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=borkmann@iogearbox$(echo .)net \
--cc=brouer@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dsahern@gmail$(echo .)com \
--cc=gtzalik@amazon$(echo .)com \
--cc=ilias.apalodimas@linaro$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rizzo@iet$(echo .)unipi.it \
--cc=sameehj@amazon$(echo .)com \
--cc=zorik@amazon$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox