Dmitry Kasatkin wrote:
> Hi,
>
> ahash allows to use HW acceleration, but usually it comes at a cost of
> additional HW related configuration overhead, such as configuring hash
> module, DMA, etc. For that reason hashing small chucks of data is
> faster doing it with shash (CPU) rather than HW ac
Ard Biesheuvel wrote:
>
> + /*
> +* Pass current's thread info pointer to sha1_ce_transform()
> +* below if we want it to play nice under preemption.
> +*/
> + if ((IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY) ||
> +
On Fri, May 09, 2014 at 08:37:58AM +0200, Ard Biesheuvel wrote:
>
> @Herbert, Jussi: care to share your opinion on the SHAx, GHASH and AES
> patches above? Herbert has already acked the ccm patch, but Catalin is
> requesting for more review and/or acknowledgements before merging
> these patches for
On Tue, May 13, 2014 at 04:19:45PM -0700, Tim Chen wrote:
>
> diff --git a/crypto/shash.c b/crypto/shash.c
> index 929058a..6f40424 100644
> --- a/crypto/shash.c
> +++ b/crypto/shash.c
> @@ -229,6 +229,42 @@ int shash_ahash_update(struct ahash_request *req, struct
> shash_desc *desc)
> }
> EXPOR
On Tue, May 13, 2014 at 04:40:58PM -0700, Tim Chen wrote:
> On Wed, 2014-05-14 at 07:34 +0800, Herbert Xu wrote:
>
> >
> > Why do we need this patch since kmap_atomic is equivalent to
> > page_address plus preempt_disable on x86-64?
>
> For multi-buffers, you may still have some data lanes with
On Wed, 2014-05-14 at 07:34 +0800, Herbert Xu wrote:
>
> Why do we need this patch since kmap_atomic is equivalent to
> page_address plus preempt_disable on x86-64?
For multi-buffers, you may still have some data lanes with jobs
that are partially completed when you need to put the thread
to sl
On Tue, May 13, 2014 at 04:19:42PM -0700, Tim Chen wrote:
> For x86_64, it is not necessary to incur the additional overhead in
> kmap_atomic to map the scatter gather buffer to a linear address.
> Mapping the address directly will allow in x86_64 allows multi-buffer
> crypto hash alogrithms to hav
This patch introduces the multi-buffer scheduler which is responsible
for submitting scatter-gather buffers from several SHA1 jobs to the
multi-buffer algorithm. It also contains the flush routine to that's
called by the crypto daemon to complete the job when no new jobs arrive
before the deadline
This patch introduces the routines used to submit and flush buffers
belonging to SHA1 crypto jobs to the SHA1 multibuffer algorithm. It is
implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 327
For x86_64, it is not necessary to incur the additional overhead in
kmap_atomic to map the scatter gather buffer to a linear address.
Mapping the address directly will allow in x86_64 allows multi-buffer
crypto hash alogrithms to have several unfinished buffers with their
address stored in job cont
This patch introduces the data structures and prototypes of functions
needed for computing SHA1 hash using multi-buffer. Included are the
structures of the multi-buffer SHA1 job, job scheduler in C and x86
assembly.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_mb_mgr_datastruct.S | 2
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm. The idea of the multi-buffer algorihtm is to put
data streams from multiple jobs in a wide (AVX2) register and then
take advantage
This patch introduces the assembly routines to do SHA1 computation on
buffers belonging to serveral jobs at once. The assembly routines are
optimized with AVX2 instructions that have 8 data lanes and using AVX2
registers.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_x8_avx2.S | 472 +
In this patch series, we introduce the multi-buffer crypto algorithm on
x86_64 and apply it to SHA1 hash computation. The multi-buffer technique
takes advantage of the 8 data lanes in the AVX2 registers and allows
computation to be performed on data from multiple jobs in parallel.
This allows us t
On 01.05.2014 18:51, Ard Biesheuvel wrote:
> The Crypto Extensions based SHA1 implementation uses the NEON register file,
> and hence runs with preemption disabled. This patch adds a TIF_NEED_RESCHED
> check to its inner loop so we at least give up the CPU voluntarily when we
> are running in proce
On Fri, May 09, 2014 at 08:34:40PM -0500, Kim Phillips wrote:
> From: Vakul Garg
>
> Re-initialize keys_fit_inline to avoid using its stale encrypt() shared
> descriptor value prior to building descriptors for the decrypt() and
> givencrypt() cases.
>
> Signed-off-by: Vakul Garg
> [reworded com
On Mon, May 12, 2014 at 11:31:05AM +0900, Jingoo Han wrote:
> On Friday, May 09, 2014 8:36 PM, Arnd Bergmann wrote:
> >
> > As we are preparing to enable multiplatform support on EXYNOS,
> > we can no longer include mach/*.h or plat/*.h headers from device
> > drivers.
> >
> > The s5p-sss driver
On Fri, May 09, 2014 at 12:57:39AM +0300, Stanimir Vabanov wrote:
> Hi Herbert,
>
> On 04/28/2014 11:59 AM, Herbert Xu wrote:
> > On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote:
> >>
> >> +#define QCE_MAJOR_VERSION50x05
> >> +#define QCE_QUEUE_LENGTH 50
> >
> > What is
Hi Linus:
This push fixes a NULL pointer dereference on allocation failure
in caam, as well as a regression in the ctr mode on s390 that was
added with the recent concurrency fixes.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
master.kernel.org:/pub/
On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
> Hello Jet,
>
> this is likely not CAN related, as
>
> # CONFIG_CAN is not set
>
> and all the CAN changes introduced by Marc's merge are not even compiled in
> your setup.
>
> So I assume the issue somewhere in the netlink or ipv6 stuff (see comm
On 05/13/2014 09:43 AM, Marc Kleine-Budde wrote:
> On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
>> Hello Jet,
>>
>> this is likely not CAN related, as
>>
>> # CONFIG_CAN is not set
>>
>> and all the CAN changes introduced by Marc's merge are not even compiled in
>> your setup.
>>
>> So I assume t
21 matches
Mail list logo
