netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Saeed Mahameed <saeed@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	"David S . Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, Raed Salem <raeds@nvidia.com>,
	ipsec-devel <devel@linux-ipsec.org>
Subject: Re: [PATCH xfrm-next v2 0/6] Extend XFRM core to allow full offload configuration
Date: Tue, 23 Aug 2022 07:48:37 +0300	[thread overview]
Message-ID: <YwRcJaythk/kM5Kf@unreal> (raw)
In-Reply-To: <20220822212716.yji3ugbppse7snfy@sx1>

On Mon, Aug 22, 2022 at 02:27:16PM -0700, Saeed Mahameed wrote:
> On 22 Aug 09:33, Jakub Kicinski wrote:
> > On Mon, 22 Aug 2022 11:54:42 +0300 Leon Romanovsky wrote:
> > > On Mon, Aug 22, 2022 at 10:41:05AM +0200, Steffen Klassert wrote:
> > > > On Fri, Aug 19, 2022 at 10:53:56AM -0700, Jakub Kicinski wrote:
> > > > > Yup, that's what I thought you'd say. Can't argue with that use case
> > > > > if Steffen is satisfied with the technical aspects.
> > > >
> > > > Yes, everything that can help to overcome the performance problems
> > > > can help and I'm interested in this type of offload. But we need to
> > > > make sure the API is usable by the whole community, so I don't
> > > > want an API for some special case one of the NIC vendors is
> > > > interested in.
> > > 
> > > BTW, we have a performance data, I planned to send it as part of cover
> > > letter for v3, but it is worth to share it now.
> > > 
> > >  ================================================================================
> > >  Performance results:
> > > 
> > >  TCP multi-stream, using iperf3 instance per-CPU.
> > >  +----------------------+--------+--------+--------+--------+---------+---------+
> > >  |                      | 1 CPU  | 2 CPUs | 4 CPUs | 8 CPUs | 16 CPUs | 32 CPUs |
> > >  |                      +--------+--------+--------+--------+---------+---------+
> > >  |                      |                   BW (Gbps)                           |
> > >  +----------------------+--------+--------+-------+---------+---------+---------+
> > >  | Baseline             | 27.9   | 59     | 93.1  | 92.8    | 93.7    | 94.4    |
> > >  +----------------------+--------+--------+-------+---------+---------+---------+
> > >  | Software IPsec       | 6      | 11.9   | 23.3  | 45.9    | 83.8    | 91.8    |
> > >  +----------------------+--------+--------+-------+---------+---------+---------+
> > >  | IPsec crypto offload | 15     | 29.7   | 58.5  | 89.6    | 90.4    | 90.8    |
> > >  +----------------------+--------+--------+-------+---------+---------+---------+
> > >  | IPsec full offload   | 28     | 57     | 90.7  | 91      | 91.3    | 91.9    |
> > >  +----------------------+--------+--------+-------+---------+---------+---------+
> > > 
> > >  IPsec full offload mode behaves as baseline and reaches linerate with same amount
> > >  of CPUs.
> > > 
> 
> Just making sure: Baseline == "Clear text TCP" ?

Yes, baseline is plain TCP without any encryption.

We can get higher numbers with Tariq's improvements, but it was not
important to achieve maximum as we are interested to see differences
between various modes.

Thanks

  parent reply	other threads:[~2022-08-23  4:48 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-16  8:59 [PATCH xfrm-next v2 0/6] Extend XFRM core to allow full offload configuration Leon Romanovsky
2022-08-16  8:59 ` [PATCH xfrm-next v2 1/6] xfrm: add new full offload flag Leon Romanovsky
2022-08-16  8:59 ` [PATCH xfrm-next v2 2/6] xfrm: allow state full offload mode Leon Romanovsky
2022-08-18 10:12   ` Steffen Klassert
2022-08-18 13:28     ` Leon Romanovsky
2022-08-22  8:01       ` Steffen Klassert
2022-08-22  8:46         ` Leon Romanovsky
2022-08-16  8:59 ` [PATCH xfrm-next v2 3/6] xfrm: add an interface to offload policy Leon Romanovsky
2022-08-16  8:59 ` [PATCH xfrm-next v2 4/6] xfrm: add TX datapath support for IPsec full offload mode Leon Romanovsky
2022-08-18 10:24   ` Steffen Klassert
2022-08-18 13:34     ` Leon Romanovsky
2022-08-22  8:04       ` Steffen Klassert
2022-08-22  8:50         ` Leon Romanovsky
2022-08-16  8:59 ` [PATCH xfrm-next v2 5/6] xfrm: add RX datapath protection " Leon Romanovsky
2022-08-18 10:27   ` Steffen Klassert
2022-08-18 13:36     ` Leon Romanovsky
2022-08-22  8:06       ` Steffen Klassert
2022-08-22  9:35         ` Leon Romanovsky
2022-08-16  8:59 ` [PATCH xfrm-next v2 6/6] xfrm: enforce separation between priorities of HW/SW policies Leon Romanovsky
2022-08-17  2:54 ` [PATCH xfrm-next v2 0/6] Extend XFRM core to allow full offload configuration Jakub Kicinski
2022-08-17  5:22   ` Leon Romanovsky
2022-08-17 18:10     ` Jakub Kicinski
2022-08-18  5:24       ` Leon Romanovsky
2022-08-18 10:10         ` Steffen Klassert
2022-08-18 12:51           ` Leon Romanovsky
2022-08-19  1:54           ` Jakub Kicinski
2022-08-19  2:34         ` Jakub Kicinski
2022-08-19  5:52           ` Leon Romanovsky
2022-08-19 15:47             ` Jakub Kicinski
2022-08-19 16:01               ` Jason Gunthorpe
2022-08-19 17:53                 ` Jakub Kicinski
2022-08-22  8:41                   ` Steffen Klassert
2022-08-22  8:54                     ` Leon Romanovsky
2022-08-22 16:33                       ` Jakub Kicinski
2022-08-22 21:27                         ` Saeed Mahameed
2022-08-23  0:17                           ` Jakub Kicinski
2022-08-23  5:22                             ` Steffen Klassert
2022-08-23 14:06                               ` Leon Romanovsky
2022-08-23  4:48                           ` Leon Romanovsky [this message]
2022-08-26 12:20                             ` Jason Gunthorpe
2022-08-23  5:34                         ` Leon Romanovsky
2022-08-18 10:09 ` Steffen Klassert
2022-08-18 13:26   ` Leon Romanovsky
2022-08-22  8:34     ` Steffen Klassert
2022-08-22  9:34       ` Leon Romanovsky

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=YwRcJaythk/kM5Kf@unreal \
    --to=leon@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devel@linux-ipsec.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jgg@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=raeds@nvidia.com \
    --cc=saeed@kernel.org \
    --cc=steffen.klassert@secunet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).