Date: Tue, 5 Nov 2019 17:48:48 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= <olivier@freebsd.org> Cc: Kurt Jaeger <pi@freebsd.org>, freebsd-net@freebsd.org Subject: Re: 10g IPsec ? Message-ID: <20191106014848.GI8521@funkthat.com> In-Reply-To: <CA%2Bq%2BTcogf6uiCX=LiENB=hpz3V-hJtKY-4m_2YYbxbuy9bFVww@mail.gmail.com> References: <20191104194637.GA71627@home.opsec.eu> <20191105191514.GG8521@funkthat.com> <CA%2Bq%2BTcogf6uiCX=LiENB=hpz3V-hJtKY-4m_2YYbxbuy9bFVww@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Olivier Cochard-Labb wrote this message on Tue, Nov 05, 2019 at 23:45 +0100:
> On Tue, Nov 5, 2019 at 8:15 PM John-Mark Gurney <jmg@funkthat.com> 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.
Can't the async crypto sysctl be used to help offload the crypto to
other threads?
if (V_async_crypto)
crp->crp_flags |= CRYPTO_F_ASYNC | CRYPTO_F_ASYNC_KEEPORDER;
But yes, I think the biggest limitation will be pushing all the data
through a single queue...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191106014848.GI8521>