From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: 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: Wed, 17 Aug 2022 08:22:02 +0300 [thread overview]
Message-ID: <Yvx6+qLPWWfCmDVG@unreal> (raw)
In-Reply-To: <20220816195408.56eec0ed@kernel.org>
On Tue, Aug 16, 2022 at 07:54:08PM -0700, Jakub Kicinski wrote:
> On Tue, 16 Aug 2022 11:59:21 +0300 Leon Romanovsky wrote:
> > The following series extends XFRM core code to handle new type of IPsec
> > offload - full offload.
> >
> > In this mode, the HW is going to be responsible for whole data path, so
> > both policy and state should be offloaded.
>
> This is making a precedent for full tunnel offload in netdev, right?
Not really. SW IPsec supports two modes: tunnel and transport.
However HW and SW stack supports only offload of transport mode.
This is the case for already merged IPsec crypto offload mode and
the case for this full offload.
> Could you indulge us with a more detailed description, motivation,
> performance results, where the behavior of offload may differ (if at
> all), what visibility users have, how SW and HW work together on the
> datapath? Documentation would be great.
IPsec full offload is actually improved version of IPsec crypto mode,
In full mode, HW is responsible to trim/add headers in addition to
decrypt/encrypt. In this mode, the packet arrives to the stack as already
decrypted and vice versa for TX (exits to HW as not-encrypted).
My main motivation is to perform IPsec on RoCE traffic and in our
preliminary results, we are able to do IPsec full offload in line
rate. The same goes for ETH traffic.
Regarding behavior differences - they are not expected.
We (Raed and me) tried very hard to make sure that IPsec full offload
will behave exactly as SW path.
There are some limitations to reduce complexity, but they can be removed
later if needs will arise. Right now, none of them are "real" limitations
for various *swarn forks, which we extend as well.
Some of them:
1. Request to have reqid for policy and state. I use reqid for HW
matching between policy and state.
2. Automatic separation between HW and SW priorities, because HW sees
packet first.
3. Only main template is supported.
4. No fallback to SW if IPsec HW failed to handle packet. HW should drop
such packet.
Visibility:
Users can see the mode through iproute2
https://lore.kernel.org/netdev/cover.1652179360.git.leonro@nvidia.com/
and see statistics through ethtool.
Documentation will come as well. I assume that IPsec folks are familiar
with this topic as it was discussed in IPsec coffee hour.
Thanks
next prev parent reply other threads:[~2022-08-17 5:22 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 [this message]
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
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=Yvx6+qLPWWfCmDVG@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=devel@linux-ipsec.org \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=raeds@nvidia.com \
--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