Re: git: b0e020764aae - main - ipsec + ktls: cannot coexists

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 <kib@FreeBSD.org>
> > AuthorDate: 2024-12-28 08:30:49 +0000
> > Commit:     Konstantin Belousov <kib@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.