Dan McDonald wrote:
On Fri, Jun 08, 2007 at 02:20:01PM -0400, James Carlson wrote:
Garrett D'Amore writes:
I think the answer is no, here, because of ip_rput. There is a risk
that some badly written driver will call putnext() to pass a packet
upstream while holding a lock. Cetainly I think this can be called
while the driver is operating in interrupt context.
Holding a lock across putnext is just a programming error. How far do
we have to go to protect against programming errors? (Should the
stack check for freed mblks?)
So Jim, are you saying that I *could* call crypto synchronously because the
correct behavior is not to hold locks? If so, that's encouraging for the HW
crypto folks in the audience.
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.
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.
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?
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
