From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: "Machulsky\, Zorik" <zorik@amazon.com>, "Jubran\,
Samih" <sameehj@amazon.com>,
"davem\@davemloft.net" <davem@davemloft.net>,
"netdev\@vger.kernel.org" <netdev@vger.kernel.org>, "Woodhouse\,
David" <dwmw@amazon.co.uk>, "Matushevsky\,
Alexander" <matua@amazon.com>, "Bshara\,
Saeed" <saeedb@amazon.com>, "Wilson\, Matt" <msw@amazon.com>,
"Liguori\, Anthony" <aliguori@amazon.com>, "Bshara\,
Nafea" <nafea@amazon.com>, "Tzalik\, Guy" <gtzalik@amazon.com>,
"Belgazal\, Netanel" <netanel@amazon.com>, "Saidi\,
Ali" <alisaidi@amazon.com>, "Herrenschmidt\,
Benjamin" <benh@amazon.com>, "Kiyanovski\,
Arthur" <akiyano@amazon.com>,
Daniel Borkmann <borkmann@iogearbox.net>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Jakub Kicinski <jakub.kicinski@netronome.com>,
"xdp-newbies\@vger.kernel.org" <xdp-newbies@vger.kernel.org>,
brouer@redhat.com
Subject: Re: XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support)
Date: Wed, 26 Jun 2019 17:14:32 +0200 [thread overview]
Message-ID: <87ef3gbcpz.fsf@toke.dk> (raw)
In-Reply-To: <20190626164059.4a9511cf@carbon>
Jesper Dangaard Brouer <brouer@redhat.com> writes:
> On Wed, 26 Jun 2019 13:52:16 +0200
> Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
>> Jesper Dangaard Brouer <brouer@redhat.com> writes:
>>
>> > On Tue, 25 Jun 2019 03:19:22 +0000
>> > "Machulsky, Zorik" <zorik@amazon.com> wrote:
>> >
>> >> On 6/23/19, 7:21 AM, "Jesper Dangaard Brouer" <brouer@redhat.com> wrote:
>> >>
>> >> On Sun, 23 Jun 2019 10:06:49 +0300 <sameehj@amazon.com> wrote:
>> >>
>> >> > This commit implements the basic functionality of drop/pass logic in the
>> >> > ena driver.
>> >>
>> >> Usually we require a driver to implement all the XDP return codes,
>> >> before we accept it. But as Daniel and I discussed with Zorik during
>> >> NetConf[1], we are going to make an exception and accept the driver
>> >> if you also implement XDP_TX.
>> >>
>> >> As we trust that Zorik/Amazon will follow and implement XDP_REDIRECT
>> >> later, given he/you wants AF_XDP support which requires XDP_REDIRECT.
>> >>
>> >> Jesper, thanks for your comments and very helpful discussion during
>> >> NetConf! That's the plan, as we agreed. From our side I would like to
>> >> reiterate again the importance of multi-buffer support by xdp frame.
>> >> We would really prefer not to see our MTU shrinking because of xdp
>> >> support.
>> >
>> > Okay we really need to make a serious attempt to find a way to support
>> > multi-buffer packets with XDP. With the important criteria of not
>> > hurting performance of the single-buffer per packet design.
>> >
>> > I've created a design document[2], that I will update based on our
>> > discussions: [2] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org
>> >
>> > The use-case that really convinced me was Eric's packet header-split.
>> >
>> >
>> > Lets refresh: Why XDP don't have multi-buffer support:
>> >
>> > XDP is designed for maximum performance, which is why certain driver-level
>> > use-cases were not supported, like multi-buffer packets (like jumbo-frames).
>> > As it e.g. complicated the driver RX-loop and memory model handling.
>> >
>> > The single buffer per packet design, is also tied into eBPF Direct-Access
>> > (DA) to packet data, which can only be allowed if the packet memory is in
>> > contiguous memory. This DA feature is essential for XDP performance.
>> >
>> >
>> > One way forward is to define that XDP only get access to the first
>> > packet buffer, and it cannot see subsequent buffers. For XDP_TX and
>> > XDP_REDIRECT to work then XDP still need to carry pointers (plus
>> > len+offset) to the other buffers, which is 16 bytes per extra buffer.
>>
>> Yeah, I think this would be reasonable. As long as we can have a
>> metadata field with the full length + still give XDP programs the
>> ability to truncate the packet (i.e., discard the subsequent pages)
>
> You touch upon some interesting complications already:
>
> 1. It is valuable for XDP bpf_prog to know "full" length?
> (if so, then we need to extend xdp ctx with info)
>
> But if we need to know the full length, when the first-buffer is
> processed. Then realize that this affect the drivers RX-loop, because
> then we need to "collect" all the buffers before we can know the
> length (although some HW provide this in first descriptor).
>
> We likely have to change drivers RX-loop anyhow, as XDP_TX and
> XDP_REDIRECT will also need to "collect" all buffers before the packet
> can be forwarded. (Although this could potentially happen later in
> driver loop when it meet/find the End-Of-Packet descriptor bit).
A few more points (mostly thinking out loud here):
- In any case we probably need to loop through the subsequent
descriptors in all cases, right? (i.e., if we run XDP on first
segment, and that returns DROP, the rest that are part of the packet
still need to be discarded). So we may as well delay XDP execution
until we have the whole packet?
- Will this allow us to run XDP on hardware-assembled GRO super-packets?
-Toke
next prev parent reply other threads:[~2019-06-26 15:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-23 7:06 [RFC V1 net-next 0/1] Introduce xdp to ena sameehj
2019-06-23 7:06 ` [RFC V1 net-next 1/1] net: ena: implement XDP drop support sameehj
2019-06-23 14:09 ` Jesper Dangaard Brouer
2019-06-23 14:21 ` Jesper Dangaard Brouer
2019-06-25 3:19 ` Machulsky, Zorik
2019-06-26 8:38 ` XDP multi-buffer incl. jumbo-frames (Was: [RFC V1 net-next 1/1] net: ena: implement XDP drop support) Jesper Dangaard Brouer
2019-06-26 11:52 ` Toke Høiland-Jørgensen
2019-06-26 14:40 ` Jesper Dangaard Brouer
2019-06-26 15:01 ` Toke Høiland-Jørgensen
2019-06-26 15:20 ` Willem de Bruijn
2019-06-26 16:42 ` Jonathan Lemon
2019-06-26 20:00 ` Jesper Dangaard Brouer
2019-06-27 22:07 ` Jonathan Lemon
2019-06-28 8:46 ` Jesper Dangaard Brouer
2019-06-26 15:14 ` Toke Høiland-Jørgensen [this message]
2019-06-26 16:36 ` Jesper Dangaard Brouer
2019-06-28 7:14 ` Eelco Chaudron
2019-06-28 7:46 ` Toke Høiland-Jørgensen
2019-06-28 11:49 ` Eelco Chaudron
2019-06-28 8:22 ` Jesper Dangaard Brouer
2019-06-23 14:28 ` [RFC V1 net-next 1/1] net: ena: implement XDP drop support David Ahern
2019-06-23 14:51 ` Maciej Fijalkowski
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=87ef3gbcpz.fsf@toke.dk \
--to=toke@redhat.com \
--cc=akiyano@amazon.com \
--cc=alexei.starovoitov@gmail.com \
--cc=aliguori@amazon.com \
--cc=alisaidi@amazon.com \
--cc=benh@amazon.com \
--cc=borkmann@iogearbox.net \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=dwmw@amazon.co.uk \
--cc=gtzalik@amazon.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jakub.kicinski@netronome.com \
--cc=matua@amazon.com \
--cc=msw@amazon.com \
--cc=nafea@amazon.com \
--cc=netanel@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=saeedb@amazon.com \
--cc=sameehj@amazon.com \
--cc=xdp-newbies@vger.kernel.org \
--cc=zorik@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).