Date: Thu, 7 Nov 2019 08:52:48 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Lawrence Stewart <lstewart@freebsd.org>, =?UTF-8?Q?Olivier_Cochard-Labb=c3=a9?= <olivier@freebsd.org>, John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-net@freebsd.org, Kurt Jaeger <pi@freebsd.org> Subject: Re: 10g IPsec ? Message-ID: <261b842d-51eb-4522-6ef5-0672e5d1594e@grosbein.net> In-Reply-To: <f4051158-b80c-3c54-10c8-f1b01c401f0d@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
07.11.2019 8:36, Lawrence Stewart wrote: >>> AES-GCM can run at over 1GB/sec on a single core, so as long as the >>> traffic can be processed by multiple threads (via multiple queues >>> for example), it should be doable. >>> >>> >> I didn't bench this setup (10Gb/s IPSec) but I believe we will have the >> same problem with IPSec as with all VPN setups (like PPPoE or GRE): the >> IPSec tunnel will generate one IP flow preventing load sharing between all >> the NIC's RSS queues. >> I'm not aware of improvement to remove this limitation. > > I never understood why the IPsec SPI couldn't be used to shard > traffic... does anyone know if there is a technical reason why doing so > would be problematic? Generic way do distribute load over CPUs is distinct hardware receive queues of NIC using distinct interrupts to deliver packets to the host while interrupts are bound to distinct CPU cores. It needs hardware capable of splitting packet stream by IPsec SPI and I'm aware of only some 40Gpbs Intel NICs that can be programmed to do so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?261b842d-51eb-4522-6ef5-0672e5d1594e>