diff options
author | David S. Miller <davem@davemloft.net> | 2016-02-18 17:42:41 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2016-02-18 17:42:41 +0100 |
commit | f169af2cdc069f5c7a6bce8e565728b841ae56e0 (patch) | |
tree | b3a306ae943dab972f6acd6d311b4b3a21a3efaa /drivers/net/vxlan.c | |
parent | net_sched: Improve readability of filter processing (diff) | |
parent | nfnetlink: Revert "nfnetlink: add support for memory mapped netlink" (diff) | |
download | linux-f169af2cdc069f5c7a6bce8e565728b841ae56e0.tar.xz linux-f169af2cdc069f5c7a6bce8e565728b841ae56e0.zip |
Merge branch 'netlink-mmap-remove'
Florian Westphal says:
====================
netlink: remove mmapped netlink support
As discussed during netconf 2016 in Seville, this series removes
CONFIG_NETLINK_MMAP.
Close to three years after it was merged it has retained several problems
that do not appear to be fixable.
No official netfilter libmnl release contains support for mmap backed netlink
sockets. No openvswitch release makes use of it either.
To use the mmap interface, userspace not only has to probe for mmap netlink
support, it also has to implement a recv/socket receive path in order to
handle messages that exceed the size of an rx ring element (NL_MMAP_STATUS_COPY).
So if there are odd programs out there that attempt to use MMAP netlink
they should continue to work as they already need a socket based code path
to work properly.
The actual revert (first patch) has a list of problems.
The followup patches remove a couple of helpers that are no longer needed
after the revert.
I did a few tests with mmap vs. socket based interface on a 4.4 based
kernel on an i7-4790 box and there are no performance advantages:
loopback, single nfqueue, queueing in -t filter INPUT:
traffic generated by 8 * ping -q -f localhost:
socket backend:
real 0m27.325s
user 0m3.993s
sys 0m23.292s
with mmap ring backend:
real 0m29.054s
user 0m4.924s
sys 0m24.127s
with single tcp stream, unidirectional, loopback mtu set at 1500
(nc localhost discard < /dev/zero > /dev/null):
socket interface:
time nfqdump -b $((8 * 1024 * 1024 * 1024)) -w /dev/null
real 0m15.960s
user 0m1.756s
sys 0m11.143s
mmap ring:
real 0m16.441s
user 0m3.040s
sys 0m13.687s
socket interface nfqdump[1] with --gso option (i.e. MTU is exceeded,
no kernel-side segmentation and checksum fixups) completes in about 5s.
I also tested dumping a conntrack table with 1m entries.
On my box this takes about 2.4 seconds for both mmap and socket backend:
time LD_PRELOAD=../../src/.libs/libmnl.so ./nfct-dump-sk > /dev/null
mnl_cb_run: Success
messages: 1000000
real 0m2.485s
user 0m1.085s
sys 0m1.400s
time LD_PRELOAD=../../src/.libs/libmnl.so ./nfct-dump-mmap > /dev/null
messages: 1000000
real 0m2.451s
user 0m1.124s
sys 0m1.328s
[1] https://git.breakpoint.cc/cgit/fw/nfqdump.git/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/vxlan.c')
0 files changed, 0 insertions, 0 deletions