[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170205031854.GD73775@ast-mbp.thefacebook.com>
Date: Sat, 4 Feb 2017 19:18:56 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...com>,
"David S . Miller" <davem@...emloft.net>,
David Ahern <dsa@...ulusnetworks.com>,
Tejun Heo <tj@...nel.org>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Thomas Graf <tgraf@...g.ch>,
Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net] bpf: expose netns inode to bpf programs
On Sat, Feb 04, 2017 at 09:08:38AM -0800, Andy Lutomirski wrote:
> > So use-case would be that someone wants to attach the very same
> > prog via tc to various netdevs sitting in different netns, and
> > that prog looks up a map, controlled by initns, with skb->netns_inum
> > as key and the resulting value could contain allowed feature bits
> > for that specific netns prog the skbs goes through? That would be
> > a feature, not "concern", no? At the same time, it's up to the
> > user or mgmt app what gets loaded so f.e. it might just as well
> > tailor/optimize the progs individually for the devs sitting in
> > netns-es to avoid such map lookup.
>
> Agreed. I don't see why you would install the exact same program on
> two sockets in different netnses if the program contains, say, an
> ifindex. Why not just install a variant with the right ifindex into
> each socket?
for some use cases it may be feasible to generate different
program on the fly for every netns that is created. Some people
generate them already for things like IP addresses. Like to stop
an attack to particular vip the fastest xdp program has
that vip built-in, then compiled on the fly and loaded.
In other cases people prefer to have one program compiled once
and thoroughly tested offline, since some folks are worried
that on-the-fly compilation may cause generated code to
be rejected by the verifier.
Therefore new program for every netns may be acceptable
to some users, but not all.
Powered by blists - more mailing lists