public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia•com>
To: Leon Romanovsky <leon@kernel•org>
Cc: Saeed Mahameed <saeed@kernel•org>,
	Jakub Kicinski <kuba@kernel•org>,
	Steffen Klassert <steffen.klassert@secunet•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: Fri, 26 Aug 2022 09:20:56 -0300	[thread overview]
Message-ID: <Ywi6qA7EsBJwEa5x@nvidia.com> (raw)
In-Reply-To: <YwRcJaythk/kM5Kf@unreal>

On Tue, Aug 23, 2022 at 07:48:37AM +0300, Leon Romanovsky wrote:
> 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.

BW is only part of the goal here, a significant metric is how much
hypervisor CPU power is consumed by the ESP operation.

It is not any different than vlan or other encapsulating offloads
where the ideal is to not interrupt the hypervisor CPU at all.

Jason

  reply	other threads:[~2022-08-26 12:23 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
2022-08-26 12:20                             ` Jason Gunthorpe [this message]
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=Ywi6qA7EsBJwEa5x@nvidia.com \
    --to=jgg@nvidia$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=devel@linux-ipsec$(echo .)org \
    --cc=herbert@gondor$(echo .)apana.org.au \
    --cc=kuba@kernel$(echo .)org \
    --cc=leon@kernel$(echo .)org \
    --cc=netdev@vger$(echo .)kernel.org \
    --cc=raeds@nvidia$(echo .)com \
    --cc=saeed@kernel$(echo .)org \
    --cc=steffen.klassert@secunet$(echo .)com \
    /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