I'm Cc:ing crypto-discuss too, because this is as much a crypto issue as it
is a networking one.
On Thu, Jul 19, 2007 at 05:56:32PM -0700, Chi-Chang Lin wrote:
> > 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.
>
> If ip_input() is in soft ring thread (which is always the case in Niagara
> 2), is it ok to be cv_wait()'ed ?
There's still the problem with crypto providers possibly calling kmem_alloc()
with KM_SLEEP, which is just Bad News (TM).
We make a change in IP and it affects everything, not just any upcoming
goodies. And I'm not clear what interrupte level the soft-ring servicing
threads operate at.
The Summary:
We've found that if IPsec can call the crypto framework with NO
ASYNCHRONY, we can use soft-rings to get big scalability wins. The
problem is, we can't (for now) guarantee that crypto providers won't:
- Block an inordinately long time on a lock of some sort.
- Call kmem_alloc() with KM_SLEEP.
- Other behavior which while safe in user context, in
interrupt context may cause untold havoc to the system.
What we'd like to see:
From networking: Am I missing any SPECIFIC pitfalls beyond the two
items in the list above that need to be called out
beyond "other behavior"?
From crypto: Can we rustle all crypto providers (HW and SW) and make
them obey certain rules regarding their synchronous
providers?
Beyond that, maybe can we have the framework return and
error from a synchronous call that allows the caller
(IPsec) to try again asynchronously? That way, we
cover the smart HW (like N2) and SW (like the native
Solaris crypto code), and the dumb HW and SW too?
All suggestions and comments are welcome!
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
