Hi Paul, > > 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....
Our card has proven so far that it definitely does. We do have more work ahead of us, though. > > > 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? The kernel stack supports anything the hardware would support. Software-API-wise, the driver is responsible to filter out unsupported offloads. Our hardware currently does AES-GCM. AES-CBC with SHA is planned, but not available yet. > > >>> 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. > This relates to a similar discussion I had with strongswan developers. The daemon explicitly configures the SA to offload on a device, so it is aware of this "bind" (although the SA still works on other interfaces Without the NIC offload) Then, if a netlink route change notification affects this, the daemon may re-configure the SA. This functionality is very similar to MOBIKE. If you have code paths to handle that, then theoretically you could re-use large parts of the same logic. Ilan. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
