From: ebiederm@xmission.com (Eric W. Biederman)
To: David Ahern <dsa@cumulusnetworks.com>
Cc: Alexei Starovoitov <ast@fb.com>,
"David S . Miller" <davem@davemloft.net>,
Daniel Borkmann <daniel@iogearbox.net>, Tejun Heo <tj@kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH v4 net] bpf: add bpf_sk_netns_id() helper
Date: Thu, 16 Feb 2017 16:08:52 +1300 [thread overview]
Message-ID: <878tp6al2z.fsf@xmission.com> (raw)
In-Reply-To: <cc15d1fa-dd38-c01b-7a42-9eaf206d98a2@cumulusnetworks.com> (David Ahern's message of "Wed, 15 Feb 2017 19:16:03 -0700")
David Ahern <dsa@cumulusnetworks.com> writes:
> On 2/14/17 12:21 AM, Eric W. Biederman wrote:
>>> in cases where bpf programs are looking at sockets and packets
>>> that belong to different netns, it could be useful to get an id
>>> that uniquely identify a netns within the whole system.
>> It could be useful but there is no unique namespace id.
>>
>
> Have you given thought to a unique namespace id? Networking tracepoints
> for example could really benefit from a unique id.
An id from the perspective of a process in the initial instance of every
namespace is certainly possible.
A truly unique id is just not maintainable. Think of the question how
do you assign every device in the world a rguaranteed unique ip address
without coordination, that is routable. It is essentially the same
problem.
AKA it is theoretically possible and very expensive. It is much easier
and much more maintainable for identifiers to have scope and only be
unique within that scope.
Eric
next prev parent reply other threads:[~2017-02-16 3:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 2:02 [PATCH v4 net] bpf: add bpf_sk_netns_id() helper Alexei Starovoitov
2017-02-07 10:41 ` Daniel Borkmann
2017-02-08 18:16 ` David Miller
2017-02-14 7:21 ` Eric W. Biederman
2017-02-16 2:16 ` David Ahern
2017-02-16 3:08 ` Eric W. Biederman [this message]
2017-02-16 3:18 ` David Ahern
2017-02-16 3:25 ` Andy Lutomirski
2017-02-16 3:35 ` David Ahern
2017-02-16 3:45 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878tp6al2z.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=ast@fb.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dsa@cumulusnetworks.com \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.