<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - running nft command creates lag for forwarded packets"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1127">1127</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>running nft command creates lag for forwarded packets
</td>
</tr>
<tr>
<th>Product</th>
<td>nftables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>Gentoo
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>major
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>nft
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pablo@netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>karel@unitednetworks.cz
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>