Date: Wed, 6 Nov 2019 09:10:07 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: =?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: <1aa5b9f3-affb-1068-449a-385b18daa270@grosbein.net> 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
06.11.2019 5:45, Olivier Cochard-Labbé wrote: > 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. Some speedup may be achieved switching from direct NETISR mode to deferred mode, so interrupt processing merely places traffic to the ISR queue. Several (net.isr.numthreads) other kernel threads will process incoming traffic later including bpf, IPSEC, filtering, routing lookups, NETGRAPH etc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1aa5b9f3-affb-1068-449a-385b18daa270>