Date: Thu, 7 Nov 2019 10:52:11 +0100 (CET) From: Damien DEVILLE <damien.deville@stormshield.eu> To: Eugene Grosbein <eugen@grosbein.net> Cc: Lawrence Stewart <lstewart@freebsd.org>, olivier <olivier@freebsd.org>, freebsd-net@freebsd.org, Kurt Jaeger <pi@freebsd.org> Subject: Re: 10g IPsec ? Message-ID: <972466586.1921723.1573120331472.JavaMail.zimbra@stormshield.eu> In-Reply-To: <54db0c82-ad44-13ed-8e1f-702557f331e5@grosbein.net> References: <20191104194637.GA71627@home.opsec.eu> <20191105191514.GG8521@funkthat.com> <CA%2Bq%2BTcogf6uiCX=LiENB=hpz3V-hJtKY-4m_2YYbxbuy9bFVww@mail.gmail.com> <f4051158-b80c-3c54-10c8-f1b01c401f0d@freebsd.org> <261b842d-51eb-4522-6ef5-0672e5d1594e@grosbein.net> <d2b64075-b9fe-b13d-760e-70cf0e074ea6@freebsd.org> <20191107073255.GU8521@funkthat.com> <54db0c82-ad44-13ed-8e1f-702557f331e5@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi freebsd-net, At Stormshield we have various patches related to that topic that we can sh= are. On the flow id part, we have a patch that recompute a new flowid for the IP= sec flow after encapsulation based on the spi. This force the usage of the same transmit queue on the network card side fo= r each tunnel/SPI. If you are interested i can make a review for this one to upstream it, it i= s a small and simple modification. On the single tunnel optimisation we recently took some time to optimize so= me code we made earlier and commited to FreeBSD 11 https://github.com/freebsd/freebsd/commit/fbc9da5dbe50b72a335de7a27b6834fba= 8ee3cf0 + https://github.com/freebsd/freebsd/commit/c8b6f569add600b6ce34184= 8bcc28a79fb5f273b 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 / ix= l network cards), the previous code was running around 2.4Gbps using AES-GC= M 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. Ta= ke 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 i= nterest 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 no= t in FreeBSD. We made the modification to work using kproc in the non polli= ng 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 s= ome 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, =C3=A0 8:48, Eugene Grosbein eugen@grosbein.net a =C3=A9= crit : | 07.11.2019 14:32, John-Mark Gurney wrote: |=20 |> 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. |=20 | If the host got a packet already, it can just process it without extra | re-classification. |=20 | The only case I know when such re-classification can be useful is assigni= ng | 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. |=20 | I doubt this has much practical use :-) Generally we terminate IPsec loca= lly | or route packets to other hosts without need to differ them from other tr= ansit | traffic. |=20 | _______________________________________________ | freebsd-net@freebsd.org mailing list | https://lists.freebsd.org/mailman/listinfo/freebsd-net | To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?972466586.1921723.1573120331472.JavaMail.zimbra>