<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>