10g IPsec ?

[Damien DEVILLE]

Hi freebsd-net,

At Stormshield we have various patches related to that topic that we can share.

On the flow id part, we have a patch that recompute a new flowid for the IPsec flow after encapsulation based on the spi.
This force the usage of the same transmit queue on the network card side for each tunnel/SPI.

If you are interested i can make a review for this one to upstream it, it is a small and simple modification.

On the single tunnel optimisation we recently took some time to optimize some code we made earlier and commited to FreeBSD 11
https://github.com/freebsd/freebsd/commit/fbc9da5dbe50b72a335de7a27b6834fba8ee3cf0 + https://github.com/freebsd/freebsd/commit/c8b6f569add600b6ce341848bcc28a79fb5f273b

The goal was to optimize this code in the context of a single IPsec tunnel and a single network flow in that tunnel.
On one of our high end hardware (Intel(R) Xeon(R) E-2176G with 6 cores / ixl network cards), the previous code was running around 2.4Gbps using AES-GCM with a mix of packet size whose average size was around 650 bytes.
After various heavy optimization in opencrypto/crypto.c and on IPsec stack we managed to increase the performance on the same test to around 5Gbps. Take care this is mainly targeted to the subset of opencrypto feature we are using in our products (mainly IPsec with or without hardware cryptography)

I can take some time to review and submit this big patch if there is some interest in it.
It will require some work on our side cause at the moment this patch is for FreeBSD 10.3 and has some depencies to our custom polling code which is not in FreeBSD. We made the modification to work using kproc in the non polling code but we have still to test those on an unmodified FreeBSD.

I can also share the various benchmark we did to illustrate the impact of some of the optimisation we did.

Damien

--
Damien Deville
IPS Technical Leader
http://www.stormshield.eu

Stormshield
2/6 Avenue de l'Horizon, Bat. 6 - FR 59650 Villeneuve d'Ascq

----- Le 7 Nov 19, à 8:48, Eugene Grosbein eugen at grosbein.net a écrit :

| 07.11.2019 14:32, John-Mark Gurney wrote:
| 
|> Don't we have the option of doing soft re-classification?  Where we
|> recalculate the hash, and then do a netisr defer?  I mean that'd burn
|> a bunch of extra cpu cycles, but you gotta do what you gotta do.
| 
| If the host got a packet already, it can just process it without extra
| re-classification.
| 
| The only case I know when such re-classification can be useful is assigning
| M_FLOWID to the mbuf
| so that lagg(4) using LACP could send it further using such M_FLOWID and maybe
| distribute distinct IPsec flows over distinct ports of LAGG group.
| 
| I doubt this has much practical use :-) Generally we terminate IPsec locally
| or route packets to other hosts without need to differ them from other transit
| traffic.
| 
| _______________________________________________
| freebsd-net at freebsd.org mailing list
| https://lists.freebsd.org/mailman/listinfo/freebsd-net
| To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"