[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Apr 2016 16:18:38 +0100
From: Edward Cree <ecree@...arflare.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
Jesper Dangaard Brouer <brouer@...hat.com>
CC: Daniel Borkmann <daniel@...earbox.net>,
Brenden Blanco <bblanco@...mgrid.com>, <davem@...emloft.net>,
<netdev@...r.kernel.org>, <tom@...bertland.com>,
<alexei.starovoitov@...il.com>, <gerlitz@...lanox.com>,
<john.fastabend@...il.com>
Subject: Re: [RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver
filter
On 04/04/16 15:33, Eric Dumazet wrote:
> On Mon, 2016-04-04 at 15:07 +0200, Jesper Dangaard Brouer wrote:
>
>> Argh... maybe the minimal pseudo/fake SKB is the wrong "signal" to send
>> to users of this API.
>>
>> The hole idea is that an SKB is NOT allocated yet, and not needed at
>> this level. If we start supporting calling underlying SKB functions,
>> then we will end-up in the same place (performance wise).
>
> A BPF program can access many skb fields.
>
> If you plan to support BPF, your fake skb needs to be populated like a
> real one. Looks like some code will be replicated in all drivers that
> want this facility...
>
> Or accept (document ?) that some BPF instructions are just not there.
> (hash, queue_mapping ...)
If these progs are eventually going to get pushed down into supporting
hardware, many skb things won't make sense at all at that level. I would
suggest that anything hardware wouldn't reasonably have available should
be "just not there"; I suspect that'll lead you to the right API for early
driver filter as well. And it probably won't look much like an skb.
-Ed
Powered by blists - more mailing lists