[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACby=pmSSG5P+7=wDvqwkVp_yXw9o8_pREZCLfDov_XFbueFAQ@mail.gmail.com>
Date: Thu, 3 Nov 2016 09:20:01 -0600
From: Thomas Graf <tgraf@...g.ch>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: "David S. Miller" <davem@...emloft.net>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Daniel Borkmann <daniel@...earbox.net>,
Tom Herbert <tom@...bertland.com>,
roopa <roopa@...ulusnetworks.com>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation
On 3 November 2016 at 08:52, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> On 02.11.2016 23:54, Thomas Graf wrote:
>> Why would I want to accept the overhead if I simply avoid it? Just
>> parsing the header and doing the hash lookup will add cost, cost for
>> each packet.
>
> That is true, but in case you are outside of the namespace, you still
> have to calculate the cost of doing the FIB lookup for the BPF program
> each time, too.
>
> E.g. given the lookup cost in a hash for a netnwork namespace pointer
> vs. the cost of doing a FIB lookup to get a program that does a specific
> transformation sounds at least in the big O-notiation to be in a better
> place. ;)
>
> If you have to do both anyway, probably your patchset will perform
> better, I agree.
Most containers are unprivileged, the route inside the container's
namespace is owned by the host and we can attach the BPF program
directly to the default route inside the container and all packets
egressing from the container will pass through it. That fib lookup is
needed anyway so we can leverage the cost of that lookup. We can drop
hostile packets early without ever going on L2 level.
Powered by blists - more mailing lists