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
