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

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 <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.

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