Fastd benchmarks, AES-NI gegen salsa2012

Technik
1

Moin,

ich habe gerade ein paar Benchmarks durchgeführt um den Vorteil von AES-NI bei fastd zu ermitteln. Hier sind die Testergebnisse:

salsa2012+umac (GCC, tun, 1280): 424 MBit/s
aes128-ctr+umac (GCC, tun, 1280): 432 MBit/s
salsa2012+umac (GCC, tun, 1280, LTO): 431 MBit/s
aes128-ctr+umac (GCC, tun, 1280, LTO): 427 MBit/s
salsa2012+umac (clang, tun, 1280): 411 MBit/s
aes128-ctr+umac (clang, tun, 1280): 425 MBit/s
null (GCC, tun, 1280, LTO): 538 MBit/s

(LTO = Link Time Optimization)

Als CPU kam eine Intel(R) Core™ i5 CPU M 540 @ 2.53GHz zum Einsatz. Die Benchmarks liefen jeweils 10s mit iperf. Netzwerk dazwischen war nur loopback. Die Tunnelinterfaces wurden jeweils in einen eigenen Networknamespace gelegt um den Traffic wirklich über den Tunnel zu zwingen.

4 „Gefällt mir“
2

Hmm…
Und was würde er bei „null“ in diesem Szenario tun?

3

Habe ich gerade nochmal, allerdings nur in der GCC Variante mit LTO, ergänzt: 538 MBit/s

1 „Gefällt mir“
4

Wie ist denn die Last bei sowas? Hat die CPU Langweile bei AES-NI oder liegt das Limit woanders? Ist ja recht nah beieinander alles…

5

Beide Kerne der CPU waren nahezu vollständig ausgelastet.
Zum Vergleich: ohne AES-NI hatte ich nur etwa 60 MBit/s erreicht. Auch mit voll ausgelasteter CPU.

2 „Gefällt mir“
6

Auch bei Null/tun/LTO?

7

Ja klar. Der Scheduler hat ja ein Interesse daran die CPU beschäftigt zu halten.