From: Christian Brauner <christian@brauner.io>
To: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, pombredanne@nexb.com,
kstewart@linuxfoundation.org, gregkh@linuxfoundation.org,
dsahern@gmail.com, fw@strlen.de, ktkhai@virtuozzo.com,
lucien.xin@gmail.com, jakub.kicinski@netronome.com,
jbenc@redhat.com, nicolas.dichtel@6wind.com,
Christian Brauner <christian@brauner.io>
Subject: [PATCH net-next v1 0/5] rtnetlink: add IFA_IF_NETNSID for RTM_GETADDR
Date: Mon, 3 Sep 2018 06:37:12 +0200 [thread overview]
Message-ID: <20180903043717.20136-1-christian@brauner.io> (raw)
Hey,
# v1 introduction:
The only functional change is the export of rtnl_get_net_ns_capable()
which is needed in case ipv6 is built as a module.
Note, I did not change the property name to IFA_TARGET_NSID as there was
no clear agreement what would be preferred. My personal preference is to
keep the IFA_IF_NETNSID name because it aligns naturally with the
IFLA_IF_NETNSID property for RTM_*LINK requests. Jiri seems to prefer
this name too.
However, if there is agreement that another property name makes more
sense I'm happy to send a v2 that changes this.
## Performance:
To test this patchset I performed 1 million getifaddrs() requests
against a network namespace containing 5 interfaces (lo, eth{0-4}). The
first test used a network namespace aware getifaddrs() implementation I
wrote and the second test used the traditional setns() + getifaddrs()
method. The results show that this patchsets allows userspace to cut
retrieval time in half:
1. netns_getifaddrs(): 82 microseconds
2. setns() + getifaddrs(): 162 microseconds
# v0 introduction:
A while back we introduced and enabled IFLA_IF_NETNSID in
RTM_{DEL,GET,NEW}LINK requests (cf. [1], [2], [3], [4], [5]). This has led
to signficant performance increases since it allows userspace to avoid
taking the hit of a setns(netns_fd, CLONE_NEWNET), then getting the
interfaces from the netns associated with the netns_fd. Especially when a
lot of network namespaces are in use, using setns() becomes increasingly
problematic when performance matters.
Usually, RTML_GETLINK requests are followed by RTM_GETADDR requests (cf.
getifaddrs() style functions and friends). But currently, RTM_GETADDR
requests do not support a similar property like IFLA_IF_NETNSID for
RTM_*LINK requests.
This is problematic since userspace can retrieve interfaces from another
network namespace by sending a IFLA_IF_NETNSID property along but
RTM_GETLINK request but is still forced to use the legacy setns() style of
retrieving interfaces in RTM_GETADDR requests.
The goal of this series is to make it possible to perform RTM_GETADDR
requests on different network namespaces. To this end a new IFA_IF_NETNSID
property for RTM_*ADDR requests is introduced. It can be used to send a
network namespace identifier along in RTM_*ADDR requests. The network
namespace identifier will be used to retrieve the target network namespace
in which the request is supposed to be fulfilled. This aligns the behavior
of RTM_*ADDR requests with the behavior of RTM_*LINK requests.
## Security:
- The caller must have assigned a valid network namespace identifier for
the target network namespace.
- The caller must have CAP_NET_ADMIN in the owning user namespace of the
target network namespace.
Thanks!
Christian
[1]: commit 7973bfd8758d ("rtnetlink: remove check for IFLA_IF_NETNSID")
[2]: commit 5bb8ed075428 ("rtnetlink: enable IFLA_IF_NETNSID for RTM_NEWLINK")
[3]: commit b61ad68a9fe8 ("rtnetlink: enable IFLA_IF_NETNSID for RTM_DELLINK")
[4]: commit c310bfcb6e1b ("rtnetlink: enable IFLA_IF_NETNSID for RTM_SETLINK")
[5]: commit 7c4f63ba8243 ("rtnetlink: enable IFLA_IF_NETNSID in do_setlink()")
Christian Brauner (5):
rtnetlink: add rtnl_get_net_ns_capable()
if_addr: add IFA_IF_NETNSID
ipv4: enable IFA_IF_NETNSID for RTM_GETADDR
ipv6: enable IFA_IF_NETNSID for RTM_GETADDR
rtnetlink: move type calculation out of loop
include/net/rtnetlink.h | 1 +
include/uapi/linux/if_addr.h | 1 +
net/core/rtnetlink.c | 19 +++++++---
net/ipv4/devinet.c | 38 +++++++++++++++-----
net/ipv6/addrconf.c | 70 ++++++++++++++++++++++++++++--------
5 files changed, 101 insertions(+), 28 deletions(-)
--
2.17.1
next reply other threads:[~2018-09-03 4:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-03 4:37 Christian Brauner [this message]
2018-09-03 4:37 ` [PATCH net-next v1 1/5] rtnetlink: add rtnl_get_net_ns_capable() Christian Brauner
2018-09-03 4:37 ` [PATCH net-next v1 2/5] if_addr: add IFA_IF_NETNSID Christian Brauner
2018-09-03 4:37 ` [PATCH net-next v1 3/5] ipv4: enable IFA_IF_NETNSID for RTM_GETADDR Christian Brauner
2018-09-04 3:11 ` David Ahern
2018-09-04 6:50 ` Jiri Benc
2018-09-04 7:20 ` Nicolas Dichtel
2018-09-04 16:27 ` David Ahern
2018-09-03 4:37 ` [PATCH net-next v1 4/5] ipv6: " Christian Brauner
2018-09-03 14:56 ` Kirill Tkhai
2018-09-03 4:37 ` [PATCH net-next v1 5/5] rtnetlink: move type calculation out of loop Christian Brauner
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=20180903043717.20136-1-christian@brauner.io \
--to=christian@brauner.io \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=fw@strlen.de \
--cc=gregkh@linuxfoundation.org \
--cc=jakub.kicinski@netronome.com \
--cc=jbenc@redhat.com \
--cc=kstewart@linuxfoundation.org \
--cc=ktkhai@virtuozzo.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=pombredanne@nexb.com \
--cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®