Krishna - That sounds like a good option to me.
thanks, -gary Krishna Yenduri wrote: >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 >_______________________________________________ >crypto-discuss mailing list >crypto-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/crypto-discuss > >
