_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev
Markus Stockhausen <[email protected]> wrote:
>
> [PATCH v1 0/3] SHA256 for PPC/SPE
>
> The following patches add support for SIMD accelerated SHA256
> calculation on PPC processors with SPE instruction set. The
> implementation takes care of the following constraints:
>
> - independant of processor endianess
> - fallback to generic code if called from interrupt context
> - disable preemtion only for short intervals
Thanks for the patch! Unfortunately the interrupt context test
is a bummer because that means your code won't be used by IPsec
at all.
Would it be possible to relax the conditions similar to sha1_ssse3
on x86? If not how about going async with cryptd?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> Von: [email protected] [[email protected]]" im Auftrag von "Herbert Xu [[email protected]]
> Gesendet: Montag, 26. Januar 2015 01:18
> An: Markus Stockhausen
> Cc: [email protected]; [email protected]
> Betreff: Re: [PATCH v1 0/3] SHA256 for PPC/SPE
>
> Markus Stockhausen <[email protected]> wrote:
> >
> > [PATCH v1 0/3] SHA256 for PPC/SPE
> >
> > The following patches add support for SIMD accelerated SHA256
> > calculation on PPC processors with SPE instruction set. The
> > implementation takes care of the following constraints:
> >
> > - independant of processor endianess
> > - fallback to generic code if called from interrupt context
> > - disable preemtion only for short intervals
>
> Thanks for the patch! Unfortunately the interrupt context test
> is a bummer because that means your code won't be used by IPsec
> at all.
>
> Would it be possible to relax the conditions similar to sha1_ssse3
> on x86? If not how about going async with cryptd?
@Herbert: thanks for that annotation. IPsec is the desired use case.
Do you have a programming template for the cryptd integration?
E.g. ghash-clmulni-intel_glue.c?
@linuxppc: Intel world checks for usable FPU (SSE3, ...) in the crypto
modules with
bool irq_fpu_usable(void)
{
return !in_interrupt() ||
interrupted_user_mode() ||
interrupted_kernel_fpu_idle();
}
I guess interrupted_kernel_fpu_idle() is the part that allows IPsec
inside an interrupt to make use of the accelerated module.
Explanation reads:
* On others, we can do a kernel_fpu_begin/end() pair *ONLY* if
* that pair does nothing at all: the thread must not have fpu (so
* that we don't try to save the FPU state), and TS must
* be set (so that the clts/stts pair does nothing that is
* visible in the interrupted kernel thread).
Do I have the chance to use something similiar in the PPC/SPE
case? Or is there a simple way like saving the SPE registers
myself?
Thanks in advance.
Markus
On 24/01/15 21:10, Markus Stockhausen wrote:
> [PATCH v1 0/3] SHA256 for PPC/SPE
>
> The following patches add support for SIMD accelerated SHA256
> calculation on PPC processors with SPE instruction set. The
Nice boost.
Many of the SoCs with e500 core have crypto hardware accelerators. How
does this compare?
Thanks,
Conor
> Von: Conor O'Gorman [[email protected]]
> Gesendet: Freitag, 30. Januar 2015 13:02
> An: Markus Stockhausen; [email protected]
> Cc: [email protected]
> Betreff: Re: [PATCH v1 0/3] SHA256 for PPC/SPE
>
> On 24/01/15 21:10, Markus Stockhausen wrote:
> > [PATCH v1 0/3] SHA256 for PPC/SPE
> >
> > The following patches add support for SIMD accelerated SHA256
> > calculation on PPC processors with SPE instruction set. The
>
> Nice boost.
>
> Many of the SoCs with e500 core have crypto hardware accelerators. How
> does this compare?
May sound stupid but I failed to activate the device in my TP-Link WDR4900.
The whole story here: https://community.freescale.com/message/475816
Markus