All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: <netdev@vger.kernel.org>
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
	<sowmini.varadhan@oracle.com>
Subject: [PATCH RFC] IPsec performance improvements (discussion base for the IPsec performance BoF)
Date: Thu, 4 Feb 2016 07:36:53 +0100	[thread overview]
Message-ID: <1454567826-13018-1-git-send-email-steffen.klassert@secunet.com> (raw)

This patchset adds some performance improvements for IPsec. It is a
early stage RFC version and still contains bugs. I post this now just
to have a discussion base for the IPsec performance BoF at the netdev
conference next week.

The patchset adds a GRO/GSO codepath for IPsec and tries to avoid the
linearization of the buffers whenever possible.

The GRO part seems to work well. GSO and avoiding linearization still
have problems, in particular with async crypto operations.

Below are some performance numbers.

Transport mode (measured by Sowmini Varadhan):

Baseline:

2.6 Gbps ESP-NULL
2.17 Gbps AES-GCM-256

Avoid frame copy + GSO/GRO:

8 Gbps ESP-NULL
4.2 Gbps AES-GCM-256

Forwarding with tunnel mode (measured by myself):

Baseline:

3.63 Gbps prcypt(echainiv(authenc(hmac(sha1-ssse3),cbc-aes-aesni)))

Avoid frame copy + GSO/GRO:

4.33 Gbps pcrypt(echainiv(authenc(hmac(sha1-ssse3),cbc-aes-aesni)))

I used the following cpu bindings for the pcrypt setup:

----------  TCP   ----------  ESP Tunnel     ---------   TCP   ----------
|iperf -c|------->|IPsec TX|---------------->|IPsec RX|------->|iperf -s|
----------        ----------                 ----------        ----------

cpu0           RX |        |              RX |        |
cpu1              |        | TX              |        | TX
cpu2              | crypto |                 | crypto |
cpu3              | crypto |                 | crypto |
cpu4              | crypto |                 | crypto |
cpu5              | crypto |                 | crypto |

Packet forwarding is done with four machines.
The crypto operations are isolated from the networking path.
Packets traverse the stack as follows:

- Packet is received on cpu0 (irqs pinned).
- cpu0 enqueues the crypto request to a pcrypt parallelization queue.
- Crypto is done on cpu 2-5, crypto requests are pinned round robin
  to the cpus. pcrypt ensures to keep the requests in the right order.
- After crypto is done, the requests are queued to a pcrypt
  serialization queue.
- cpu1 gets a callback from the crypto layer and does the final TX
  path.

             reply	other threads:[~2016-02-04  7:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04  6:36 Steffen Klassert [this message]
2016-02-04  6:36 ` [PATCH RFC 01/13] net: allow to leave the buffer fragmented in skb_cow_data() Steffen Klassert
2016-02-04  6:36 ` [PATCH RFC 02/13] gro: Partly revert "net: gro: allow to build full sized skb" Steffen Klassert
2016-02-04  6:36 ` [PATCH RFC 03/13] esp: Add a software GRO codepath Steffen Klassert
2016-02-04  6:36 ` [PATCH RFC 04/13] xfrm: Move device notifications to a sepatate file Steffen Klassert
2016-02-04  6:36 ` [PATCH RFC 05/13] xfrm: Add callbacks for IPsec GSO offloading Steffen Klassert
2016-02-04  6:36 ` [PATCH RFC 06/13] net: Add xfrm offload callbacks to struct net_device Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 07/13] net: Add ESP offload features Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 08/13] esp4: Add a software GSO codepath Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 09/13] esp: Avoid skb_cow_data whenever possible Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 10/13] xfrm: Add basic infrastructure for IPsec device offloading Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 11/13] net: Enable IPsec software GSO Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 12/13] crypto: Make the page handling of hash walk compatible to networking Steffen Klassert
2016-02-04  6:37 ` [PATCH RFC 13/13] net: Allow IPsec GSO for locally sent traffic 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=1454567826-13018-1-git-send-email-steffen.klassert@secunet.com \
    --to=steffen.klassert@secunet.com \
    --cc=netdev@vger.kernel.org \
    --cc=sowmini.varadhan@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.