#
65f264dc |
| 23-Jul-2024 |
Konstantin Belousov <kib@FreeBSD.org> |
ipsec_offload: indirect two more functions on the ipsec.ko module load
Specifically, ipsec_accel_on_ifdown() and ipsec_accel_drv_sa_lifetime_update() should be present in kernel for future mlx5en dr
ipsec_offload: indirect two more functions on the ipsec.ko module load
Specifically, ipsec_accel_on_ifdown() and ipsec_accel_drv_sa_lifetime_update() should be present in kernel for future mlx5en driver to be statically linkable into the kernel built with IPSEC_HOOKS + IPSEC_OFFLOAD.
Sponsored by: NVIDIA networking
show more ...
|
#
240b7bfe |
| 14-Feb-2024 |
Konstantin Belousov <kib@FreeBSD.org> |
ipsec_offload: offload inner checksums calculations for UDP/TCP/TSO
and allow the interface driver to declare such support.
Sponsored by: NVIDIA networking Differential revision: https://reviews.fr
ipsec_offload: offload inner checksums calculations for UDP/TCP/TSO
and allow the interface driver to declare such support.
Sponsored by: NVIDIA networking Differential revision: https://reviews.freebsd.org/D44221
show more ...
|
#
ef2a572b |
| 22-Aug-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
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 i
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
show more ...
|