[Bug 1127] New: running nft command creates lag for forwarded packets

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1127

            Bug ID: 1127
           Summary: running nft command creates lag for forwarded packets
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Gentoo
            Status: NEW
          Severity: major
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: karel at unitednetworks.cz

We have several routers with Gentoo x86-64 kernels 4.9.9 or 4.10.1 with about
150 nftables rules (nftables used are commit da3f503, date 2017-1-03). Hardware
used are Xeons or i7-7700K with 10Gbe Intel or Solarflare NICs. There are few
sets, maps and flows. Any nft command, be it listing sets, maps, flows or
writing rules creates lag for forwarded packets. In test case, ICMP packets
going through boxes have normally about 5ms latency. When running nft
(regardless command for listing set with few items or with several thousand
items) latencies go up to 30-100ms. This is observed when router throughput is
from 600Mbps to 2Gbps. When throughput is about 300Mbps, latecies go up too,
but to 8-12ms. Routers are using multiple NICs queues with affinity to CPU
cores, maximum load when tests were performed was about 10-20%. Userspace
processes (including nft) are affined to other cores than NICs queues. 

Older boxes with iptables but similar ruleset have no such behaviour. Running
"iptables -t mangle -L -v -n", which lists tens of thousands of rules have
almost no effect on latency of forwarded packets (we observed 0 - 1ms).

It looks like nft have some kind of global lock for netfilter kernel, which
stops forwarding packets when nft is running, regardless of actual nft command
performed.

Can anyone explain to me that behaviour ? Can it be fixed ? Its quite a problem
for us because we use hundreds of nft commands per day and such spikes in
latencies of forwarded packets are deal breaker.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170308/49f72d12/attachment.html>