[PATCH] crypto: n2 - Use platform_register/unregister_drivers()

From: Thierry Reding These new helpers simplify implementing multi-driver modules and properly handle failure to register one driver by unregistering all previously registered drivers. Signed-off-by: Thierry Reding --- drivers/crypto/n2_core.c | 17

Re: ipsec impact on performance

On (12/02/15 12:41), David Laight wrote: > You are getting 0.7 Gbps with ass-ccm-a-128, scale the esp-null back to > that and it would use 7/18*71 = 27% of the cpu. > So 69% of the cpu in the a-128 case is probably caused by the > encryption itself. > Even if the rest of the code cost nothing

[PATCH v4 3/5] crypto: AES CBC multi-buffer scheduler

This patch implements in-order scheduler for encrypting multiple buffers in parallel supporting AES CBC encryption with key sizes of 128, 192 and 256 bits. It uses 8 data lanes by taking advantage of the SIMD instructions with XMM registers. The multibuffer manager and scheduler is mostly

Re: [PATCH v3 5/5] crypto: AES CBC multi-buffer glue code

On Tue, 2015-12-01 at 09:19 -0800, Tim Chen wrote: > On Thu, 2015-11-26 at 16:49 +0800, Herbert Xu wrote: > > On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote: > > > > > > On the decrypt path, we don't need to use multi-buffer algorithm > > > as aes-cbc decrypt can be parallelized

Re: [RFC] KEYS: Exposing {a,}symmetric key ops to userspace and other bits

On Sun, 2015-11-22 at 09:41 -0500, Mimi Zohar wrote: > On Fri, 2015-11-20 at 11:07 +, David Howells wrote: > > > > (*) Add Mimi's patches to allow keys/keyrings to be marked undeletable. > > This > > is for the purpose of creating blacklists and to prevent people from > >

[PATCH v4 4/5] crypto: AES CBC by8 encryption

This patch introduces the assembly routine to do a by8 AES CBC encryption in support of the AES CBC multi-buffer implementation. Encryption of 8 data streams of a key size are done simultaneously. Originally-by: Chandramouli Narayanan Signed-off-by: Tim Chen

[PATCH v4 2/5] crypto: AES CBC multi-buffer data structures

This patch introduces the data structures and prototypes of functions needed for doing AES CBC encryption using multi-buffer. Included are the structures of the multi-buffer AES CBC job, job scheduler in C and data structure defines in x86 assembly code. Originally-by: Chandramouli Narayanan

[PATCH v4 5/5] crypto: AES CBC multi-buffer glue code

This patch introduces the multi-buffer job manager which is responsible for submitting scatter-gather buffers from several AES CBC jobs to the multi-buffer algorithm. The glue code interfaces with the underlying algorithm that handles 8 data streams of AES CBC encryption in parallel. AES key

[PATCH v4 1/5] crypto: Multi-buffer encryption infrastructure support

In this patch, the infrastructure needed to support multibuffer encryption implementation is added: a) Enhace mcryptd daemon to support blkcipher requests. b) Update configuration to include multi-buffer encryption build support. For an introduction to the multi-buffer implementation, please

Re: ipsec impact on performance

On Wed, Dec 2, 2015 at 1:12 PM, Sowmini Varadhan wrote: > On (12/02/15 13:07), Tom Herbert wrote: >> That's easy enough to add to flow dissector, but is SPI really >> intended to be used an L4 entropy value? We would need to consider the > > yes. To quote

Re: ipsec impact on performance

On (12/02/15 13:07), Tom Herbert wrote: > That's easy enough to add to flow dissector, but is SPI really > intended to be used an L4 entropy value? We would need to consider the yes. To quote https://en.wikipedia.org/wiki/Security_Parameter_Index "This works like port numbers in TCP and UDP

Re: ipsec impact on performance

On (12/02/15 14:01), Tom Herbert wrote: > No, please don't persist is this myopic "we'll get to IPv6 later" > model! IPv6 is a real protocol, it has significant deployment of the > Internet, and there are now whole data centers that are IPv6 only > (e.g. FB), and there are plenty of use cases of

Re: [PATCH] crypto: n2 - Use platform_register/unregister_drivers()

From: Thierry Reding Date: Wed, 2 Dec 2015 17:16:36 +0100 > From: Thierry Reding > > These new helpers simplify implementing multi-driver modules and > properly handle failure to register one driver by unregistering all > previously registered

Re: ipsec impact on performance

On Wed, Dec 2, 2015 at 12:50 PM, Sowmini Varadhan wrote: > On (12/02/15 12:41), David Laight wrote: >> You are getting 0.7 Gbps with ass-ccm-a-128, scale the esp-null back to >> that and it would use 7/18*71 = 27% of the cpu. >> So 69% of the cpu in the a-128 case is

Re: ipsec impact on performance

On Wed, 2015-12-02 at 16:12 -0500, Sowmini Varadhan wrote: > IPv6 would be an interesting academic exercise Really, you made my day ! -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: ipsec impact on performance

On (12/02/15 07:53), Steffen Klassert wrote: > > I'm currently working on a GRO/GSO codepath for IPsec too. The GRO part > works already. I decapsulate/decrypt the packets on layer2 with a esp GRO > callback function and reinject them into napi_gro_receive(). So in case > the decapsulated packet

Re: ipsec impact on performance

On (12/02/15 11:56), David Laight wrote: > > Gbps peak cpu util > > esp-null 1.8 71% > > aes-gcm-c-2561.6 79% > > aes-ccm-a-1280.7 96% > > > > That trend made me think that if we can get esp-null to be as close > > as possible to GSO/GRO, the rest will

RE: ipsec impact on performance

From: Sowmini Varadhan > Sent: 01 December 2015 18:37 ... > I was using esp-null merely to not have the crypto itself perturb > the numbers (i.e., just focus on the s/w overhead for now), but here > are the numbers for the stock linux kernel stack > Gbps peak cpu util > esp-null

RE: ipsec impact on performance

From: Sowmini Varadhan > Sent: 02 December 2015 12:12 > On (12/02/15 11:56), David Laight wrote: > > > Gbps peak cpu util > > > esp-null 1.8 71% > > > aes-gcm-c-2561.6 79% > > > aes-ccm-a-1280.7 96% > > > > > > That trend made me think that if we can get

Re: ipsec impact on performance

On (12/02/15 12:41), David Laight wrote: > > Also what/how are you measuring cpu use. > I'm not sure anything on Linux gives you a truly accurate value > when processes are running for very short periods. I was using mpstat, while running iperf. Should I be using something else? or running it

Re: ipsec impact on performance

On 12/02/2015 03:56 AM, David Laight wrote: From: Sowmini Varadhan Sent: 01 December 2015 18:37 ... I was using esp-null merely to not have the crypto itself perturb the numbers (i.e., just focus on the s/w overhead for now), but here are the numbers for the stock linux kernel stack