Hi Paul,

Thank you for your feedback!

I see that Steffen already answered most of your questions.
I'll just add some extra details.

> So is this a new layer of offloading that works separately from any
> existing hardware offload? Does it only apply to nic cards? What if
> someone has some dedicated non-NIC PCI offloading card like the Intel
> QuickAssist?
> https://www-ssl.intel.com/content/www/us/en/ethernet-products/gigabit-
> server-adapters/quickassist-adapter-for-servers.html

Yes, I forgot to explicitly say it - this is offloading the crypto work
to the network hardware.

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.

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.

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

Swan-dev mailing list

Reply via email to