On Wed, 30 Nov 2016, Ilan Tayari wrote:
This way IPSec benefits from plenty of other NIC offloads, such as RX and
TX check summing, GSO, and so on.
The NIC hardware has a chance to do all of these on the plaintext payload
just before encrypting it.
If one uses crypto-offload not in the NIC, such as AES-NI or even Quick-
Assist, then all these goodies can't happen.
Ahh, that is interesting. I had not expected that the nic could beat a
multi core cpu with this....
In addition, dedicated crypto offload hardware requires that all the
payload passes over the PCI bus 3 times:
From RAM to crypto hardware, from crypto hardware back to RAM, and then
from RAM to NIC (assuming all are doing DMA).
Under high bandwidths (we are testing 40Gbps), this can put extra stress
on the system. Eventually the CPU is able to do only a little with all
the cycles it saved not doing crypto.
Cool! I have not seen 40gbps of ipsec traffic. Do these cards support
AES-GCM, or is this using AES-CBC with a SHA authentication?
I would love to see support for all of this in libreswan as well.
We'd be happy to support it, although the failure-then-retry API is
something I'm very reluctant about. I'd rather send a flag to the kernel
to tell it what to do on offload failure, so we keep our current API of
sending 1 XFRM message and getting 1 XFRM answer.
This is the main reason I wrote to the list.
We want to get your feedback and comments, and you probably want to
understand and/or influence our decisions.
And again, thank you for reaching out to us. It would be great to add
support for this.
Another question I had is how you would handle nic changes? Let's say we
have an IPsec SA up and running over one nic, and the machine's default
route changes so it goes over another nic, what is (or should?) happen?
Currently, we do not "tie" our IPsec SA's to a specific nic.
Paul
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
