On Fri, Jun 08, 2007 at 12:28:52PM -0700, [EMAIL PROTECTED] wrote: > > Dan, we're already seeing some issues with IPFilter in the chain > of events with pfhooks because it takes "longer" than normal for > packets to be processed and performance takes a tumble.
Oh yeah, latency has always been a problem with IPsec. > The solution to this problem is to increase the number of threads > that are capable of picking up packets and delivering them up > through IP. At present this requires adding tweaks to /etc/system. > Crossbow allegedly helps fix this properly. Per-SPI fanout on inbound packets is Good Enough(TM) with enough soft rings, but as you say, it's an /etc/system tweak today. > If IPsec packets are being processed synchronously, how long are > you expecting users will be prepared to wait for IPsec to return > before the next packet (maybe a ping) will be answered? A synchronous call to IPsec crypto processing assumes that the inbound packets are optimally scattered across servicing cores. On outbound, it assumes multiple senders. You can force IPsec to use asynchronous crypto all the time using ipsecalgs(1M) if you wish (and no reboot required, either). But even with async. IPsec crypto, some HW providers, AND the crypto framework infrastructure for HW providers, may force things to a single thread. Dan _______________________________________________ networking-discuss mailing list [email protected]
