[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06280af8-5451-c423-d295-a5f3f51e63cf@mojatatu.com>
Date: Fri, 23 Sep 2016 07:13:30 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Tom Herbert <tom@...bertland.com>, davem@...emloft.net,
netdev@...r.kernel.org
Cc: kernel-team@...com, tariqt@...lanox.com, bblanco@...mgrid.com,
alexei.starovoitov@...il.com, eric.dumazet@...il.com,
brouer@...hat.com
Subject: Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
On 16-09-20 06:00 PM, Tom Herbert wrote:
> This patch creates an infrastructure for registering and running code at
> XDP hooks in drivers. This is based on the orignal XDP?BPF and borrows
> heavily from the techniques used by netfilter to make generic nfhooks.
>
> An XDP hook is defined by the xdp_hook_ops. This structure contains the
> ops of an XDP hook. A pointer to this structure is passed into the XDP
> register function to set up a hook. The XDP register function mallocs
> its own xdp_hook_ops structure and copies the values from the
> xdp_hook_ops passed in. The register function also stores the pointer
> value of the xdp_hook_ops argument; this pointer is used in subsequently
> calls to XDP to identify the registered hook.
>
> The interface is defined in net/xdp.h. This includes the definition of
> xdp_hook_ops, functions to register and unregister hook ops on a device
> or individual instances of napi, and xdp_hook_run that is called by
> drivers to run the hooks.
>
Tom,
perused the thread and it seems you are serious ;->
Are we heading towards Frankenstein Avenue?
The whole point behind letting in XDP is so that _small programs_
can be written to do some quick thing. eBPF 4K program limit was
touted as the check and bound. eBPF sounded fine.
This sounds like a huge contradiction.
cheers,
jamal
Powered by blists - more mailing lists