On Thu, 16 Jan 2025, Konstantin Belousov wrote:
On Wed, Jan 15, 2025 at 11:59:58PM +0000, Bjoern A. Zeeb wrote:
On Mon, 13 Jan 2025, Konstantin Belousov wrote:
The branch main has been updated by kib:
URL:
https://cgit.FreeBSD.org/src/commit/?id=b0e020764aae970545357b0f146dcba7b4b55864
commit b0e020764aae970545357b0f146dcba7b4b55864
Author: Konstantin Belousov <k...@freebsd.org>
AuthorDate: 2024-12-28 08:30:49 +0000
Commit: Konstantin Belousov <k...@freebsd.org>
CommitDate: 2025-01-13 19:29:31 +0000
ipsec + ktls: cannot coexists
Ignore my ignorance but that description sounds bad.
Do you mean on a per-packet base or in general on a machine, i.e.,
(1) an individual packet cannot be processed by ktls and ipsec
(2) a host can either run ktls or ipsec but not both?
After this change, we are at the #1.
Before, we were at #2.
This change maps mbuf chains that are to be processed by sw IPSEC. So
the change makes KTLS and IPSEC compatible.
Mark said that there are plans to make sw IPSEC to fully handle unmapped
packets.
Either sounds like (half) a bug to me that should be fixed by the way
but I am so out of the ipsec stack that I don't know current implications.
What is the reason a packet could not first be KTLS handled and then put
into IPsec (for some part of its journey)?
Talking about software implementations, KTLS mbufs are unmapped, and IPSEC
was not prepared to handle that, so we remap them.
For inline offload on network cards (talking about mlx5), current offload
engines can do only one crypto op on packet as it is processed. In other
words, either KTLS, or IPSEC inline can be done, not both.
I see. Thanks a lot for the work and explanations. Goinng from #2 ->
#1 seems very good indeed.
Lots of joy,
/bz
--
Bjoern A. Zeeb r15:7
