On 12 Jul 2024, at 13:25, Konstantin Belousov wrote:
The branch main has been updated by kib:
URL:
https://cgit.FreeBSD.org/src/commit/?id=ef2a572bf6bdcac97ef29ce631d2f50f938e1ec8
commit ef2a572bf6bdcac97ef29ce631d2f50f938e1ec8
Author: Konstantin Belousov <k...@freebsd.org>
AuthorDate: 2021-08-22 19:38:04 +0000
Commit: Konstantin Belousov <k...@freebsd.org>
CommitDate: 2024-07-12 04:27:58 +0000
ipsec_offload: kernel infrastructure
Inline IPSEC offload moves almost whole IPSEC processing from the
CPU/MCU and possibly crypto accelerator, to the network card.
The transmitted packet content is not touched by CPU during TX
operations, kernel only does the required policy and security
association lookups to find out that given flow is offloaded, and
then
packet is transmitted as plain text to the card. For driver
convenience,
a metadata is attached to the packet identifying SA which must
process
the packet. Card does encryption of the payload, padding,
calculates
authentication, and does the reformat according to the policy.
Similarly, on receive, card does the decapsulation, decryption,
and
authentification. Kernel receives the identifier of SA that was
used to process the packet, together with the plain-text packet.
Overall, payload octets are only read or written by card DMA
engine,
removing a lot of memory subsystem overhead, and saving CPU time
because
IPSEC algos calculations are avoided.
If driver declares support for inline IPSEC offload (with the
IFCAP2_IPSEC_OFFLOAD capability set and registering method table
struct
if_ipsec_accel_methods), kernel offers the SPD and SAD to driver.
Driver decides which policies and SAs can be offloaded based on
hardware capacity, and acks/nacks each SA for given interface to
kernel. Kernel needs to keep this information to make a decision
to
skip software processing on TX, and to assume processing already
done
on RX. This shadow SPD/SAD database of offloads is rooted from
policies (struct secpolicy accel_ifps, struct ifp_handle_sp) and
SAs
(struct secasvar accel_ipfs, struct ifp_handle_sav).
Some extensions to the PF_KEY socket allow to limit interfaces for
which given SP/SA could be offloaded (proposed for offload).
Also,
additional statistics extensions allow to observe
allocation/octet/use
counters for specific SA.
Since SPs and SAs are typically instantiated in non-sleepable
context,
while offloading them into card is expected to require costly
async
manipulations of the card state, calls to the driver for offload
and
termination are executed in the threaded taskqueue. It also
solves
the issue of allocating resources needed for the offload database.
Neither ipf_handle_sp nor ipf_handle_sav do not add reference to
the
owning SP/SA, the offload must be terminated before last reference
is
dropped. ipsec_accel only adds transient references to ensure
safe
pointer ownership by taskqueue.
Maintaining the SA counters for hardware-accelerated packets is
the
duty of the driver. The helper
ipsec_accel_drv_sa_lifetime_update()
is provided to hide accel infrastructure from drivers which would
use
expected callout to query hardware periodically for updates.
Reviewed by: rscheff (transport, stack integration), np
Sponsored by: NVIDIA networking
Differential revision: https://reviews.freebsd.org/D44219
---
sys/conf/files | 2 +
sys/conf/options | 1 +
sys/modules/ipsec/Makefile | 5 +-
sys/netipsec/ipsec.c | 17 +
sys/netipsec/ipsec.h | 11 +
sys/netipsec/ipsec_input.c | 11 +
sys/netipsec/ipsec_offload.c | 1061
++++++++++++++++++++++++++++++++++++++++++
sys/netipsec/ipsec_offload.h | 191 ++++++++
sys/netipsec/ipsec_output.c | 15 +
sys/netipsec/ipsec_pcb.c | 38 +-
sys/netipsec/key.c | 270 ++++++++++-
sys/netipsec/key.h | 6 +
sys/netipsec/key_debug.c | 5 +
sys/netipsec/keydb.h | 14 +
14 files changed, 1628 insertions(+), 19 deletions(-)
I’m seeing messages like `ipsec_accel_sa_install_newkey: spi 0x1001
flags 0x40 seq 0` running the test suite now.
Are those stray debug printfs?
Best regards,
Kristof