<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 17.06.2013 13:46, schrieb Martin
Willi:<br>
</div>
<blockquote cite="mid:1371469567.3064.53.camel@martin" type="cite">
<pre wrap="">Hi Jakob,
</pre>
<blockquote type="cite">
<pre wrap="">I get a bandwidth around 300 MBit/sec which is largely independent from
the MTU. While this is impressive, I have reports of over 600 MBit/sec
</pre>
</blockquote>
<pre wrap="">
In my tests between two virtual machines on a single i7-3770 I've got
about the same, 300-400 MBit/sec.
AES-GCM seems to be much faster, I could achieve rates around 900
MBit/sec. If GCM is an option, I'd definitely give that a try.</pre>
</blockquote>
I get around 660 MBit/s with aes128gcm8-modp1024; did you tune
anything else? <br>
I have two real Xeon E3-1265L. <br>
<blockquote cite="mid:1371469567.3064.53.camel@martin" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Also I observed that the encryption tasks only use some of the CPUs; I
have a bonded interface with two NICs in rr-fashion and I assume two
CPUs do the encryption for these NICs, driven by interrupts?
</pre>
</blockquote>
<pre wrap="">
Yes, by default IPsec is bound to a single core, the one that handles
interrupts for your NIC. You may have a look at the pcrypt extension [1]
that allows you to use more cores. I've never tried that myself, though.
</pre>
</blockquote>
Yes, I had already seen that paper; however I am not sure whether I
want to have self-compiled kernels on these boxes....<br>
But I could try it to see where the bottleneck is. <br>
<br>
Thx Jakob <br>
<a href="http://info-systems.de/de/impressum.html" style="color:
#999999;"></a>
<div class="moz-signature"><br>
</div>
</body>
</html>