[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-LQce=1y4SeJoUQPf9fu3dEajKfx02+ZraOR3nX2c-oTQ@mail.gmail.com>
Date: Fri, 27 Apr 2018 15:06:40 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Björn Töpel <bjorn.topel@...il.com>
Cc: "Karlsson, Magnus" <magnus.karlsson@...el.com>,
Alexander Duyck <alexander.h.duyck@...el.com>,
Alexander Duyck <alexander.duyck@...il.com>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Daniel Borkmann <daniel@...earbox.net>,
"Michael S. Tsirkin" <mst@...hat.com>,
Network Development <netdev@...r.kernel.org>,
Björn Töpel <bjorn.topel@...el.com>,
michael.lundkvist@...csson.com,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
"Singhai, Anjali" <anjali.singhai@...el.com>,
"Zhang, Qi Z" <qi.z.zhang@...el.com>
Subject: Re: [PATCH bpf-next v2 00/15] Introducing AF_XDP support
On Fri, Apr 27, 2018 at 2:12 PM, Björn Töpel <bjorn.topel@...il.com> wrote:
> 2018-04-27 19:16 GMT+02:00 Willem de Bruijn <willemdebruijn.kernel@...il.com>:
>> On Fri, Apr 27, 2018 at 8:17 AM, Björn Töpel <bjorn.topel@...il.com> wrote:
>>> From: Björn Töpel <bjorn.topel@...el.com>
>>>
>>> This patch set introduces a new address family called AF_XDP that is
>>> optimized for high performance packet processing and, in upcoming
>>> patch sets, zero-copy semantics. In this v2 version, we have removed
>>> all zero-copy related code in order to make it smaller, simpler and
>>> hopefully more review friendly. This patch set only supports copy-mode
>>> for the generic XDP path (XDP_SKB) for both RX and TX and copy-mode
>>> for RX using the XDP_DRV path. Zero-copy support requires XDP and
>>> driver changes that Jesper Dangaard Brouer is working on. Some of his
>>> work has already been accepted. We will publish our zero-copy support
>>> for RX and TX on top of his patch sets at a later point in time.
>>
>>> Changes from V1:
>>>
>>> * Fixes to bugs spotted by Will in his review
>>> * Implemented the performance otimization to BPF_MAP_TYPE_XSKMAP
>>> suggested by Will
>>
>> An xsk may only exist in one map at a time. Is this somehow assured?
>>
>
> Actually this is *not* the case. An xsk may reside in many maps, and
> multiple times in the same map. So it's not assured at all. :-)
Then can multiple call_rcu operations on xs->rcu race?
Powered by blists - more mailing lists