From nobody Thu Jan 16 00:10:53 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YYNZ31YZfz5krpJ; Thu, 16 Jan 2025 00:11:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4YYNZ22ZGrz3wCB; Thu, 16 Jan 2025 00:11:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 50G0ArvM049456; Thu, 16 Jan 2025 02:10:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 50G0ArvM049456 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 50G0Arci049454; Thu, 16 Jan 2025 02:10:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 16 Jan 2025 02:10:53 +0200 From: Konstantin Belousov To: "Bjoern A. Zeeb" Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: b0e020764aae - main - ipsec + ktls: cannot coexists Message-ID: References: <202501131930.50DJUCFg047113@gitrepo.freebsd.org> <71p14p04-5o5o-1385-1551-7733rr1qo57o@yvfgf.mnoonqbm.arg> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71p14p04-5o5o-1385-1551-7733rr1qo57o@yvfgf.mnoonqbm.arg> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4YYNZ22ZGrz3wCB X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] 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 > > AuthorDate: 2024-12-28 08:30:49 +0000 > > Commit: Konstantin Belousov > > 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.