jshotnik opened a new issue, #14429:
URL: https://github.com/apache/cloudstack/issues/14429
### problem
The system VM image has /etc/modprobe.d/aesni_intel.conf with "blacklist
aesni_intel" (systemvm/debian/etc/modprobe.d/aesni_intel.conf, commit f498ca6
from 2012, "blacklist aesni_intel module to avoid crash"). router.sh loads the
module by name (setup_aesni), but vpcrouter.sh does not. VPC routers therefore
use cbc(aes-generic) for IPsec, even when the guest CPU has the aes flag.
Measured on CloudStack 4.23.0.0, guest CPU AMD EPYC-Rome, router with 4
vCPUs, iperf3 across a site-to-site tunnel:
- stock template, ESP aes256-sha256: 0.61 to 0.82 Gbit/s, with one router
vCPU at 100% softirq;
- with aesni_intel loaded, ESP aes256-sha256: 1.05 to 1.25 Gbit/s;
- with aesni_intel loaded, IKE and ESP AES-GCM: 1.40 to 1.55 Gbit/s.
Related: with AES-NI, GCM encryption runs on several vCPUs and reorders ESP
packets. strongSwan's default charon.replay_window of 32 then drops packets as
replays (XfrmInStateSeqError reached 126,700 in one test), and multi-stream
throughput fell to about 1.0 Gbit/s. "charon { replay_window = 1024 }" in
/etc/strongswan.d/ fixed it (0 drops).
### versions
System VM template 4.22.0 and earlier. CloudStack 4.23.0.0. KVM with a guest
CPU model that exposes aes (host-model).
### The steps to reproduce the bug
1. Create a VPC on KVM with a host CPU that has AES-NI and a guest CPU model
that exposes it.
2. On the VPC router, read /proc/cpuinfo (the aes flag is there),
/proc/modules (no aesni_intel) and /proc/crypto (cbc(aes) uses aes-generic).
3. Create a site-to-site VPN and run iperf3 across it. One router vCPU sits
at 100% softirq.
### What to do about it?
Load aesni_intel on VPC routers too, when the CPU has the aes flag. We use a
systemd unit with ConditionCPUFeature=aes that runs "modprobe aesni_intel" at
boot. The 2012 crash may not apply to current kernels; we saw no kernel error
in our tests. Also consider a larger charon.replay_window, for example 1024.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
