On Tue, Dec 01, 2015 at 12:59:53PM -0500, Sowmini Varadhan wrote:
>
> I instrumented iperf with and without ipsec, just using esp-null,
> and 1 thread, to keep things simple. I'm seeing some pretty dismal
> performance numbers with ipsec, and trying to think of ways to
> improve this. Here are m
On 12/1/15 5:09 PM, Sowmini Varadhan wrote:
The not-so-great news is that I see that just adding perf tracepoints
(not even enabling them!) seems to make a small diff (3 Gbps vs 3.2 Gbps)
to my numbers. Is that mere standard-deviation, or something
one should be aware of, about perf?
existence
On (12/01/15 16:56), David Ahern wrote:
>
> Using iperf3 and AH with NULL algorithm between 2 peers connected by
> a 10G link.
>
I'm using esp-null, not AH, and iperf2, which I understand is
quite different from, and more aggressive than, iperf3 (though I'm not
sure that it matters for this sin
On 12/1/15 10:17 AM, Rick Jones wrote:
On 12/01/2015 09:59 AM, Sowmini Varadhan wrote:
But these are all still relatively small things - tweaking them
doesnt get me significantly past the 3 Gbps limit. Any suggestions
on how to make this budge (or design criticism of the patch) would
be welcome.
On (12/01/15 10:50), Rick Jones wrote:
>
> Something of a longshot, but are you sure you are still getting
> effective CKO/GRO on the receiver?
Good question. With ipsec, GRO (like GSO) gets implicitly disabled.
But when I explictly disable GRO on receiver, leaving only GSO
on sender, I can stil
On 12/01/2015 10:45 AM, Sowmini Varadhan wrote:
On (12/01/15 10:17), Rick Jones wrote:
What do the perf profiles show? Presumably, loss of TSO/GSO means
an increase in the per-packet costs, but if the ipsec path
significantly increases the per-byte costs...
For ESP-null, there's actually ver
On (12/01/15 10:17), Rick Jones wrote:
>
> What do the perf profiles show? Presumably, loss of TSO/GSO means
> an increase in the per-packet costs, but if the ipsec path
> significantly increases the per-byte costs...
For ESP-null, there's actually very little work to do - we just
need to add th
On (12/01/15 10:18), Tom Herbert wrote:
> > 8.5-9.5 Gbps clear traffic, TSO disabled, so GSO, GRO is in effect
> > 3-4 Gbps clear traffic, with both TSO/GSO disabled
> > 1.8-2 Gbps for esp-null.
>
> Are you losing checksum offload also?
I tried with both checksum offload on and off
On 12/01/2015 09:59 AM, Sowmini Varadhan wrote:
But these are all still relatively small things - tweaking them
doesnt get me significantly past the 3 Gbps limit. Any suggestions
on how to make this budge (or design criticism of the patch) would
be welcome.
What do the perf profiles show? Pres
On Tue, Dec 1, 2015 at 9:59 AM, Sowmini Varadhan
wrote:
>
> I instrumented iperf with and without ipsec, just using esp-null,
> and 1 thread, to keep things simple. I'm seeing some pretty dismal
> performance numbers with ipsec, and trying to think of ways to
> improve this. Here are my findings,
Experimental patch as promised in
http://marc.info/?l=linux-netdev&m=144899280626165&w=2
Disclaimer: this patch is only an experiment to see if xfrm can be done
post-GSO to leverage from GSO benefits. I'm sharing to get some feedback
on the general direction being pursued here.
At the moment, fo
I instrumented iperf with and without ipsec, just using esp-null,
and 1 thread, to keep things simple. I'm seeing some pretty dismal
performance numbers with ipsec, and trying to think of ways to
improve this. Here are my findings, please share feedback.
I suspect that a big part of the problem
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 inherently on a single
> > request. So most of the time the outer lay
This patch adds the following algorithms to the talitos driver:
* ecb(aes)
* ctr(aes)
* ecb(des)
* cbc(des)
* ecb(des3_ede)
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 83
drivers/crypto/talitos.h | 1 +
2 files changed, 84 ins
14 matches
Mail list logo
