| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <cover.1661260787.git.leonro@nvidia.com>
Date: Tue, 23 Aug 2022 16:31:57 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Leon Romanovsky <leonro@...dia.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Paolo Abeni <pabeni@...hat.com>, Raed Salem <raeds@...dia.com>,
Saeed Mahameed <saeedm@...dia.com>
Subject: [PATCH xfrm-next v3 0/6] Extend XFRM core to allow full offload configuration
From: Leon Romanovsky <leonro@...dia.com>
Changelog:
v3:
* I didn't hear any suggestion what term to use instead of
"full 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 - full 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 full offload is an 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).
Devices that implement IPsec full 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.
To make sure that users have a coherent picture, we require that
HW offloaded policies have always (both RX and TX) higher priorities
than SW ones.
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.
There are several deliberate limitations:
* No software fallback
* Fragments are dropped, both in RX and TX
* No sockets policies
* Only IPsec transport mode is implemented
================================================================================
Configuration:
iproute2: https://lore.kernel.org/netdev/cover.1652179360.git.leonro@nvidia.com/
Full offload mode:
ip xfrm state offload full dev <if-name> dir <in|out>
ip xfrm policy .... offload full 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 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.
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 (6):
xfrm: add new full offload flag
xfrm: allow state full offload mode
xfrm: add an interface to offload policy
xfrm: add TX datapath support for IPsec full offload mode
xfrm: add RX datapath protection for IPsec full offload mode
xfrm: enforce separation between priorities of HW/SW policies
.../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 | 3 +
include/net/netns/xfrm.h | 8 +-
include/net/xfrm.h | 104 +++++++---
include/uapi/linux/xfrm.h | 6 +
net/xfrm/xfrm_device.c | 102 +++++++++-
net/xfrm/xfrm_output.c | 12 +-
net/xfrm/xfrm_policy.c | 181 ++++++++++++++++++
net/xfrm/xfrm_user.c | 19 ++
13 files changed, 425 insertions(+), 33 deletions(-)
--
2.37.2
Powered by blists - more mailing lists