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
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 http://v
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 drivers.
>
> Signed-off-by: Thierry Reding
Acke
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 IP
On Wed, Dec 2, 2015 at 1:47 PM, Sowmini Varadhan
wrote:
> On (12/02/15 13:44), Tom Herbert wrote:
>> > IPv6 would be an interesting academic exercise, but it's going
>> > to be a while before we get RDS-TCP to go over IPv6.
>> >
>> Huh? Who said anything about RDS-TCP? I thought you were trying to
On (12/02/15 13:44), Tom Herbert wrote:
> > IPv6 would be an interesting academic exercise, but it's going
> > to be a while before we get RDS-TCP to go over IPv6.
> >
> Huh? Who said anything about RDS-TCP? I thought you were trying to
> improve IPsec performance...
yes, and it would be nice to f
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 https://en.wikipedia.org/wiki/Security_Par
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 connec
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 probably caused by the
>> encr
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 you'd
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 written
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 inherentl
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
---
arch/x86/crypto/aes-cbc-mb/aes
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 expan
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
Sig
In this patch series, we introduce AES CBC encryption that is parallelized
on x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8
data streams in parallel with SIMD instructions. Decryption is handled
as in the existing AESNI Intel CBC implementation which can already
parallelize d
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 se
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
> > removing
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 +++--
1 file changed, 7 insertio
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 for
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
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 esp-n
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 follow
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 i
24 matches
Mail list logo
