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

Reply via email to