mbox series

[xfrm-next,v7,0/8] Extend XFRM core to allow packet offload configuration

Message ID cover.1667997522.git.leonro@nvidia.com (mailing list archive)
Headers show
Series Extend XFRM core to allow packet offload configuration | expand

Message

Leon Romanovsky Nov. 9, 2022, 12:54 p.m. UTC
From: Leon Romanovsky <leonro@nvidia.com>

Changelog:
v7: As was discussed in IPsec workshop:
 * Renamed "full offload" to be "packet offload".
 * Added check that offloaded SA and policy have same device while sending packet
 * Added to SAD same optimization as was done for SPD to speed-up lookups.
v6: https://lore.kernel.org/all/cover.1666692948.git.leonro@nvidia.com
 * Fixed misplaced "!" in sixth patch.
v5: https://lore.kernel.org/all/cover.1666525321.git.leonro@nvidia.com
 * Rebased to latest ipsec-next.
 * Replaced HW priority patch with solution which mimics separated SPDs
   for SW and HW. See more description in this cover letter.
 * Dropped RFC tag, usecase, API and implementation are clear.
v4: https://lore.kernel.org/all/cover.1662295929.git.leonro@nvidia.com
 * Changed title from "PATCH" to "PATCH RFC" per-request.
 * Added two new patches: one to update hard/soft limits and another
   initial take on documentation.
 * Added more info about lifetime/rekeying flow to cover letter, see
   relevant section.
 * perf traces for crypto mode will come later.
v3: https://lore.kernel.org/all/cover.1661260787.git.leonro@nvidia.com
 * I didn't hear any suggestion what term to use instead of
   "packet offload", so left it as is. It is used in commit messages
   and documentation only and easy to rename.
 * Added performance data and background info to cover letter
 * Reused xfrm_output_resume() function to support multiple XFRM transformations
 * Add PMTU check in addition to driver .xdo_dev_offload_ok validation
 * Documentation is in progress, but not part of this series yet.
v2: https://lore.kernel.org/all/cover.1660639789.git.leonro@nvidia.com
 * Rebased to latest 6.0-rc1
 * Add an extra check in TX datapath patch to validate packets before
   forwarding to HW.
 * Added policy cleanup logic in case of netdev down event
v1: https://lore.kernel.org/all/cover.1652851393.git.leonro@nvidia.com
 * Moved comment to be before if (...) in third patch.
v0: https://lore.kernel.org/all/cover.1652176932.git.leonro@nvidia.com
-----------------------------------------------------------------------

The following series extends XFRM core code to handle a new type of IPsec
offload - packet offload.

In this mode, the HW is going to be responsible for the whole data path,
so both policy and state should be offloaded.

IPsec packet offload is an improved version of IPsec crypto mode,
In packet 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).

Devices that implement IPsec packet offload mode offload policies too.
In the RX path, it causes the situation that HW can't effectively
handle mixed SW and HW priorities unless users make sure that HW offloaded
policies have higher priorities.

It means that we don't need to perform any search of inexact policies
and/or priority checks if HW policy was discovered. In such situation,
the HW will catch the packets anyway and HW can still implement inexact
lookups.

In case specific policy is not found, we will continue with packet lookup
and check for existence of HW policies in inexact list.

HW policies are added to the head of SPD to ensure fast lookup, as XFRM
iterates over all policies in the loop.

This simple solution allows us to achieve same benefits of separate HW/SW
policies databases without over-engineering the code to iterate and manage
two databases at the same path.

To not over-engineer the code, HW policies are treated as SW ones and
don't take into account netdev to allow reuse of the same priorities for
policies databases without over-engineering the code to iterate and manage
two databases at the same path.

To not over-engineer the code, HW policies are treated as SW ones and
don't take into account netdev to allow reuse of the same priorities for
different devices.
 * No software fallback
 * Fragments are dropped, both in RX and TX
 * No sockets policies
 * Only IPsec transport mode is implemented

================================================================================
Rekeying:

In order to support rekeying, as XFRM core is skipped, the HW/driver should
do the following:
 * Count the handled packets
 * Raise event that limits are reached
 * Drop packets once hard limit is occurred.

The XFRM core calls to newly introduced xfrm_dev_state_update_curlft()
function in order to perform sync between device statistics and internal
structures. On HW limit event, driver calls to xfrm_state_check_expire()
to allow XFRM core take relevant decisions.

This separation between control logic (in XFRM) and data plane allows us
to packet reuse SW stack.

================================================================================
Configuration:

iproute2: https://lore.kernel.org/netdev/cover.1652179360.git.leonro@nvidia.com/

Full offload mode:
  ip xfrm state offload packet dev <if-name> dir <in|out>
  ip xfrm policy .... offload packet dev <if-name>
Crypto offload mode:
  ip xfrm state offload crypto dev <if-name> dir <in|out>
or (backward compatibility)
  ip xfrm state offload dev <if-name> dir <in|out>

================================================================================
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 packet offload   | 28     | 57     | 90.7  | 91      | 91.3    | 91.9    |
IPsec packet offload mode behaves as baseline and reaches linerate with same amount
of CPUs.

Setups details (similar for both sides):
* NIC: ConnectX6-DX dual port, 100 Gbps each.
  Single port used in the tests.
* CPU: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz

================================================================================
Series together with mlx5 part:
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next

Thanks

Leon Romanovsky (8):
  xfrm: add new packet offload flag
  xfrm: allow state packet offload mode
  xfrm: add an interface to offload policy
  xfrm: add TX datapath support for IPsec packet offload mode
  xfrm: add RX datapath protection for IPsec packet offload mode
  xfrm: speed-up lookup of HW policies
  xfrm: add support to HW update soft and hard limits
  xfrm: document IPsec packet offload mode

 Documentation/networking/xfrm_device.rst      |  62 +++++++--
 .../inline_crypto/ch_ipsec/chcr_ipsec.c       |   4 +
 .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c    |   5 +
 drivers/net/ethernet/intel/ixgbevf/ipsec.c    |   5 +
 .../mellanox/mlx5/core/en_accel/ipsec.c       |   4 +
 drivers/net/netdevsim/ipsec.c                 |   5 +
 include/linux/netdevice.h                     |   4 +
 include/net/xfrm.h                            | 124 ++++++++++++++----
 include/uapi/linux/xfrm.h                     |   6 +
 net/xfrm/xfrm_device.c                        | 109 +++++++++++++--
 net/xfrm/xfrm_output.c                        |  13 +-
 net/xfrm/xfrm_policy.c                        | 106 ++++++++++++++-
 net/xfrm/xfrm_state.c                         |  70 +++++++---
 net/xfrm/xfrm_user.c                          |  20 +++
 14 files changed, 474 insertions(+), 63 deletions(-)

Comments

Leon Romanovsky Nov. 15, 2022, 6:09 p.m. UTC | #1
On Wed, Nov 09, 2022 at 02:54:28PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@nvidia.com>
> 
> Changelog:
> v7: As was discussed in IPsec workshop:

Steffen, can we please merge the series so we won't miss another kernel
release?

Thanks
Steffen Klassert Nov. 15, 2022, 6:30 p.m. UTC | #2
On Tue, Nov 15, 2022 at 08:09:48PM +0200, Leon Romanovsky wrote:
> On Wed, Nov 09, 2022 at 02:54:28PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> > 
> > Changelog:
> > v7: As was discussed in IPsec workshop:
> 
> Steffen, can we please merge the series so we won't miss another kernel
> release?

I'm already reviewing the patchset. But as I said at the
IPsec workshop, there is no guarantee that it will make
it during this release cycle.
Leon Romanovsky Nov. 15, 2022, 7 p.m. UTC | #3
On Tue, Nov 15, 2022 at 07:30:20PM +0100, Steffen Klassert wrote:
> On Tue, Nov 15, 2022 at 08:09:48PM +0200, Leon Romanovsky wrote:
> > On Wed, Nov 09, 2022 at 02:54:28PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@nvidia.com>
> > > 
> > > Changelog:
> > > v7: As was discussed in IPsec workshop:
> > 
> > Steffen, can we please merge the series so we won't miss another kernel
> > release?
> 
> I'm already reviewing the patchset. But as I said at the
> IPsec workshop, there is no guarantee that it will make
> it during this release cycle.

Of course, there is no guarantee, but let's not skip it if it is ready.

Thanks
Saeed Mahameed Nov. 16, 2022, 11:07 p.m. UTC | #4
On 15 Nov 21:00, Leon Romanovsky wrote:
>On Tue, Nov 15, 2022 at 07:30:20PM +0100, Steffen Klassert wrote:
>> On Tue, Nov 15, 2022 at 08:09:48PM +0200, Leon Romanovsky wrote:
>> > On Wed, Nov 09, 2022 at 02:54:28PM +0200, Leon Romanovsky wrote:
>> > > From: Leon Romanovsky <leonro@nvidia.com>
>> > >
>> > > Changelog:
>> > > v7: As was discussed in IPsec workshop:
>> >
>> > Steffen, can we please merge the series so we won't miss another kernel
>> > release?
>>
>> I'm already reviewing the patchset. But as I said at the
>> IPsec workshop, there is no guarantee that it will make
>> it during this release cycle.
>

BTW mlx5 patches are almost ready and fully reviewed, will be ready by
early next week.

Steffen in case you will be ready, how do you want to receive the whole
package? I guess we will need to post all the patches for a final time,
including mlx5 driver.
Steffen Klassert Nov. 17, 2022, 12:20 p.m. UTC | #5
On Wed, Nov 16, 2022 at 03:07:13PM -0800, Saeed Mahameed wrote:
> On 15 Nov 21:00, Leon Romanovsky wrote:
> > On Tue, Nov 15, 2022 at 07:30:20PM +0100, Steffen Klassert wrote:
> > > On Tue, Nov 15, 2022 at 08:09:48PM +0200, Leon Romanovsky wrote:
> > > > On Wed, Nov 09, 2022 at 02:54:28PM +0200, Leon Romanovsky wrote:
> > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > >
> > > > > Changelog:
> > > > > v7: As was discussed in IPsec workshop:
> > > >
> > > > Steffen, can we please merge the series so we won't miss another kernel
> > > > release?
> > > 
> > > I'm already reviewing the patchset. But as I said at the
> > > IPsec workshop, there is no guarantee that it will make
> > > it during this release cycle.
> > 
> 
> BTW mlx5 patches are almost ready and fully reviewed, will be ready by
> early next week.
> 
> Steffen in case you will be ready, how do you want to receive the whole
> package? I guess we will need to post all the patches for a final time,
> including mlx5 driver.

I guess you want me to take both, the xfrm and mlx5 patches, right?
I'm ok with that if nobody else objects to it.

Please split it anyways into a xfrm and a mlx5 pachset. I'll
merge both separate once we are ready.


Thanks!
Leon Romanovsky Nov. 17, 2022, 12:24 p.m. UTC | #6
On Thu, Nov 17, 2022 at 01:20:43PM +0100, Steffen Klassert wrote:
> On Wed, Nov 16, 2022 at 03:07:13PM -0800, Saeed Mahameed wrote:
> > On 15 Nov 21:00, Leon Romanovsky wrote:
> > > On Tue, Nov 15, 2022 at 07:30:20PM +0100, Steffen Klassert wrote:
> > > > On Tue, Nov 15, 2022 at 08:09:48PM +0200, Leon Romanovsky wrote:
> > > > > On Wed, Nov 09, 2022 at 02:54:28PM +0200, Leon Romanovsky wrote:
> > > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > > >
> > > > > > Changelog:
> > > > > > v7: As was discussed in IPsec workshop:
> > > > >
> > > > > Steffen, can we please merge the series so we won't miss another kernel
> > > > > release?
> > > > 
> > > > I'm already reviewing the patchset. But as I said at the
> > > > IPsec workshop, there is no guarantee that it will make
> > > > it during this release cycle.
> > > 
> > 
> > BTW mlx5 patches are almost ready and fully reviewed, will be ready by
> > early next week.
> > 
> > Steffen in case you will be ready, how do you want to receive the whole
> > package? I guess we will need to post all the patches for a final time,
> > including mlx5 driver.
> 
> I guess you want me to take both, the xfrm and mlx5 patches, right?

Yes

> I'm ok with that if nobody else objects to it.
> 
> Please split it anyways into a xfrm and a mlx5 pachset. I'll
> merge both separate once we are ready.
> 
> 
> Thanks!