mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-25 07:14:36 +08:00
6ef848efc2
Christian Brauner says:
====================
rtnetlink: add IFA_TARGET_NETNSID for RTM_GETADDR
This iteration should mainly addresses the suggestion to use
IFA_TARGET_NETNSID as the property name. Additionally, an an alias for
the already existing IFLA_IF_NETNSID property is added.
Note that two additional cleanup patches (8\9 and 9\9) were added to
address concerns raised that passing more than 6 arguments to a function
will cause additional variables to be pushed onto the stack instead of
being placed into registers. The way I addressed this is by introducing
two new struct inet{6}_fill_args that are used to pass common
information down to inet{6}_fill_if*() functions shortening all those
functions to three pointer arguments.
If this is something more people than Kirill find useful they can be
kept if not they can simply be dropped in later iterations of this
series or when merging.
Here is a short overview:
1. Rename from IFA_IF_NETNSID to IFA_TARGET_NETNSID.
2. Add IFLA_TARGET_NETNSID as an alias for IFA_IFLA_NETNSID and switch
all occurrences over to the new alias.
3. Add inet4_fill_args struct to avoid passing more than 6 arguments in
inet_fill_if*() functions.
4. Add inet6_fill_args struct to avoid passing more than 6 arguments in
inet_fill_if*() functions.
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.
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
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.
- 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.
[1]: commit
|
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| firmware | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
See Documentation/00-INDEX for a list of what is contained in each file.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.