I guess I still don't see why that would be worse than spinning - in
either case the ip_input thread is not capable of doing anything.
You could make the same argument when using a software crypto
provider. I think if we're worried about holding up ip_input(),
which seems like a valid concern, then even the software crypto
providers should be handled asynchronously.
I'm not talking about consuming cycles. I'm not talking about wall
clock time considerations. I'm talking about potential deadlocks due
to cv_wait.
You must -not- under any conditions cv_wait while in ip_input's path.
Because you don't know anything about what locks or PIL the calling
context is coming from.
But no locks should be held.... If the contention is we have to guard
against a buggy NIC driver then yes. However, we will sacrifice
performance to defend against bad behavior.
-gary
-- Garrett
-gary
-- Garrett
-gary
-- Garrett
-gary
-- Garrett
Right?
_______________________________________________
networking-discuss mailing list
[email protected]
