[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJ+HfNhZXgRJVK5a3YR1-v+AenXsaioGqcexY_WMpc6j_vzMwA@mail.gmail.com>
Date: Fri, 27 Apr 2018 21:24:31 +0200
From: Björn Töpel <bjorn.topel@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...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
2018-04-27 21:06 GMT+02:00 Willem de Bruijn <willemdebruijn.kernel@...il.com>:
> 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?
Hmm, right. xsk_flush in the rcu callback might race. I'd rather not
constrain the socket to only reside in one map... I'll try to fix the
flush, and go for the constraint as a last resort. IOW, I'll spin a v3
next week!
Thanks for finding this!
Björn
Powered by blists - more mailing lists