Garrett D'Amore wrote:
[EMAIL PROTECTED] wrote:
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.
Its just _just_ locks. (Although that concern arises as well.) Its
the fact that the read you're running on may be in interrupt context.
Please, please, don't try to come up with some hackery to make this
work. Its best if we adhere to the rule that ip_input is called from
streams functions, and must adhere to the same rules that all other
streams functions follow that.... that is that thou shalt not sleep.
No one is suggesting that - we're just trying get clarification so we
can make the right decision. We could prevent the driver from sleeping
but I'd want to make that decision on a job by job basis.
I suspect we've pretty well beat this one into the ground now.
-gary
Doing anything else is likely to cause spectacular failure at some
point in the future.
-- Garrett
-gary
-- Garrett
-gary
-- Garrett
-gary
-- Garrett
-gary
-- Garrett
Right?
_______________________________________________
networking-discuss mailing list
[email protected]
