Dan McDonald wrote: >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. > >
These servicing threads are not interrupt threads and hence interrupt level is not applicable. They run as a system thread with a thread priority of minclsyspri (60). >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. > > As I understand it, the problem with unbounded wait/sleep in an interrupt thread is that we will be blocking all lower-priority interrupts in this state and it can result an unresponsive/hung system. I think we can solve the problem if IPsec were to make the kernel crypto API call in synchronous mode only if servicing_interrupt() check is not true. We can keep using the asynchronous mode if the check is true. Most outgoing packets will likely fall under this case. And incoming packets processed by a service threads like the soft ring threads will fall under this case. > 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? > > This will place too many constraints on a HW crypto provider *and* the crypto framework. I would prefer the above solution with the servicing_interrupt() check. -Krishna
