[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200122195024.4bacf33a@carbon>
Date: Wed, 22 Jan 2020 19:50:24 +0100
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: "Jubran, Samih" <sameehj@...zon.com>
Cc: Luigi Rizzo <rizzo@....unipi.it>,
"Machulsky, Zorik" <zorik@...zon.com>,
Daniel Borkmann <borkmann@...earbox.net>,
David Miller <davem@...emloft.net>,
"Tzalik, Guy" <gtzalik@...zon.com>,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Toke Høiland-Jørgensen
<toke@...hat.com>, "Kiyanovski, Arthur" <akiyano@...zon.com>,
Alexei Starovoitov <ast@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
David Ahern <dsahern@...il.com>, brouer@...hat.com
Subject: Re: XDP multi-buffer design discussion
On Sun, 19 Jan 2020 07:34:00 +0000 "Jubran, Samih" <sameehj@...zon.com> wrote:
[...]
>
> We have two proposed design solutions. One (Jesper’s) seems easier
> to implement and gives the average XDP developer the framework to
> deal with multiple buffers. The other (Luigi’s) seems more complete
> but raises a few questions:
>
> 1. The netdev's callback might be too intrusive to the net
> drivers and requires the driver to somehow save context of the
> current processed packet
>
> 2. The solution might be an overkill to the average XDP
> developer. Does the average XDP developer really need full access to
> the packet?
>
> Since Jesper's design is easier to implement as well as leaves a way
> for future extension to Luigi's design, I'm going to implement and
> share it with you.
Thanks for letting us know you are still working on this.
_WHEN_ you hit issue please feel free to reach out to me. (p.s. I'll be
in Brno at DevConf.cz the next couple of days. But will be back
Tuesday and back on IRC at Freenode channel #xdp nick:netoptimizer).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists