Agree 100%.
+1. :-)
-- Garrett
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
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>
_______________________________________________
networking-discuss mailing list
[email protected]
