From: Steffen Klassert <steffen.klassert@secunet•com>
To: Timo Teras <timo.teras@iki•fi>
Cc: Andrew Collins <bsderandrew@gmail•com>, netdev@vger•kernel.org
Subject: Re: ipsec smp scalability and cpu use fairness (softirqs)
Date: Tue, 13 Aug 2013 13:56:52 +0200 [thread overview]
Message-ID: <20130813115652.GE26773@secunet.com> (raw)
In-Reply-To: <20130813143325.364b4bab@vostro>
On Tue, Aug 13, 2013 at 02:33:25PM +0300, Timo Teras wrote:
>
> I've been now playing with pcrypt. It seems to not give significant
> boost in throughput. I've setup the cpumaps properly, and top says the
> work is distributed to appropriate kworkers, but for some reason
> throughput does not get any better. I've tested with iperf in both udp
> and tcp modes, with various amounts of threads.
>
> Is there any more synchronization points for single SA that might limit
> throughput? I've been testing with auth hmac(sha1), enc cbc(aes) -
> according to metric the CPUs are still largely idle instead of
> processing more data for better throughput. aes-gcm (without pcrypt)
> achieves better throughput even saturating my test box links.
>
> Any pointers what to test, or to pinpoint the bottleneck?
>
The only pitfall that comes to my mind is that pcrypt must be
instantiated before inserting the states. Your /proc/crypto
should show something like:
name : authenc(hmac(sha1),cbc(aes))
driver : pcrypt(authenc(hmac(sha1-generic),cbc(aes-asm)))
module : pcrypt
priority : 2100
refcnt : 1
selftest : passed
type : aead
async : yes
blocksize : 16
ivsize : 16
maxauthsize : 20
geniv : <built-in>
pcrypt is now instantiated, e.g. all new IPsec states (that do
hmac-sha1, cbc-aes) will use it, adding new states increase the
refcount.
I'll do some tests with current net-next on my own tomorrow and let
you know about the results.
next prev parent reply other threads:[~2013-08-13 11:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-12 13:01 ipsec smp scalability and cpu use fairness (softirqs) Timo Teras
2013-08-12 21:58 ` Andrew Collins
2013-08-13 6:23 ` Timo Teras
2013-08-13 7:46 ` Steffen Klassert
2013-08-13 7:57 ` Timo Teras
2013-08-13 10:45 ` Steffen Klassert
2013-08-13 11:33 ` Timo Teras
2013-08-13 11:56 ` Steffen Klassert [this message]
2013-08-13 12:41 ` Timo Teras
2013-08-20 6:19 ` Steffen Klassert
2013-08-20 6:39 ` Timo Teras
2013-08-20 6:17 ` Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130813115652.GE26773@secunet.com \
--to=steffen.klassert@secunet$(echo .)com \
--cc=bsderandrew@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=timo.teras@iki$(echo .)fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox