summaryrefslogtreecommitdiffstats
path: root/drivers/net/vxlan.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2016-02-18 17:42:41 +0100
committerDavid S. Miller <davem@davemloft.net>2016-02-18 17:42:41 +0100
commitf169af2cdc069f5c7a6bce8e565728b841ae56e0 (patch)
treeb3a306ae943dab972f6acd6d311b4b3a21a3efaa /drivers/net/vxlan.c
parentnet_sched: Improve readability of filter processing (diff)
parentnfnetlink: Revert "nfnetlink: add support for memory mapped netlink" (diff)
downloadlinux-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