Lawrence Stewart wrote this message on Thu, Nov 07, 2019 at 13:04 +1100: > On 7/11/19 12:52 pm, Eugene Grosbein wrote: > > 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. > > Right, a "consumers need to ask for it" issue more so than an inherently > problematic approach. I assumed as much but wasn't sure.
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. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"