[crypto-discuss] Re: [intel-platform-discuss] Intel Platform optimised software crypto algorithms

[Bill Holler]

Dan Mick wrote On 03/16/07 10:19,:
> Darren J Moffat wrote:
> 
>>Bill Holler wrote:
>>
>>>I will add kernel thread SSE support as part of the Intel
>>>performance project.
>>
>>what does that actually mean for us in the crypto group ?  Does it mean 
>>that the preemption handling we have today in that bignum code isn't 
>>needed and that in the future we can have SSE code compiled the same in 
>>kernel as it is in userland ?
>>
> 
> 
> I'd bet the answer is "largely unknown" at this point, but I'd be a little 
> surprised if there weren't some extra work to do in the kernel (to "claim" 
> the FPU, and then "release" it, whereas that can be done automagically for 
> user processes pretty easily with the help of traps).  But it's unknown 
> territory; I don't know that anyone's yet thought about a design.
>
> _______________________________________________
> intel-platform-discuss mailing list
> intel-platform-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/intel-platform-discuss


This is something I would like to do as part of the Intel
performance work.  :-)

There would probably need to be some new API the kernel thread
would have to invoke before using SSE to let the kernel know the
thread needs its SSE state saved.  We don't want to slow down
all kernel threads with SSE state saving as most of them will
not use this.  There may also be an API to indicate when a
kernel thread is done using SSE state, so its SSE state is no
longer saved (for performance).  If we go with this sort of
model the preemption handling in the bignum code would be
replaced with these APIs.  There are other possibilities
that should be explored.

The kernel may have to handle kernel traps if the SSE hardware
can produce them.

Bill