10g IPsec ?

[Damien DEVILLE]

Hi,

There are no limitation in term of interoperability with other IPsec stack.
Funding is not needed as working on FreeBSD is part of my day time job. Available time is more the issue ;)

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, à 14:05, Santiago Martinez sm at codenetworks.net a écrit :

| Super interesting, I'm also up for it, i guess i can help with some funding.
| 
| Santi
| 
| 
| On 2019-11-07 10:41, Kurt Jaeger wrote:
|> Hi!
|>
|>> 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.
|> Yes, please. If you have the review, please add me to it.
|>
|>> 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.
|> I would appreciate this -- would it help if my company pays some
|> money for this to make it happen ?
|>
|>> 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.
|> Again, depending on the amount of work: it would definitly be interesting.
|>
|>> I can also share the various benchmark we did to illustrate the impact of some
|>> of the optimisation we did.
|> That would be very interesting. The final point would be: How
|> interoperable is the resulting IPsec connect with non-FreeBSD
|> counterparts 8-} ?