[Bug 233759] igb (I210) + net.inet.ipsec.async_crypto=1 + aesni kills receiving queues and traffic
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Dec 3 21:58:51 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233759
Bug ID: 233759
Summary: igb (I210) + net.inet.ipsec.async_crypto=1 + aesni
kills receiving queues and traffic
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: bugs at FreeBSD.org
Reporter: lev at FreeBSD.org
I'm benchmarking system with FreeBSD 13-CURRENT (r340933) configured as "VPN
border router". It receives traffic via igb0 (I210) and pass it with encryption
via IPsec tunnel mode via igb1 (I210 too).
CPU supports AES-NI, so it is enabled. I'm using aes-128-gcm cipher.
Incoming traffic has characteristics which allow to employ all 4 queues of
igb0, which run on 4 cores of 4-core CPU, it could be seen in "top -SH" output
and under heavy load queues consume 400% of CPU, 100% each. Everything works as
expected.
But when I set "sysctl net.inet.ipsec.async_crypto=1" strange thing happens:
some igb0 queues stop to work. Sometimes it is 1 queue, sometimes 2 queues, and
sometimes 3 (I never seen 4 queues stop to work, though). Stopped queues don't
consume CPU and don't pass traffic, so 1/4, 2/4 or 3/4 of incoming traffic is
simply lost. Even if traffic is very light (say, 64 packet per second!),
traffic which was classified to "stopped" queues is lost. "tcpdump -i igb0"
doesn't show it.
Only reboot reset this behavior, setting "sysctl net.inet.ipsec.async_crypto=0"
doesn't help.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list