From nobody Mon Mar 20 09:57:09 2023 X-Original-To: freebsd-net@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 4Pg9Bd2LjHz40VQK for ; Mon, 20 Mar 2023 09:57:13 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pg9Bc6zrrz4Jc2; Mon, 20 Mar 2023 09:57:12 +0000 (UTC) (envelope-from tuexen@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:a80e:acdc:23d1:329c]) (Authenticated sender: micmac) by mail-n.franken.de (Postfix) with ESMTPSA id AA50B71EC2022; Mon, 20 Mar 2023 10:57:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: assigning different TCP stacks to the jails From: tuexen@freebsd.org In-Reply-To: <41AF7F1A-CBE8-4197-852C-4B727FB1C54B@FreeBSD.org> Date: Mon, 20 Mar 2023 10:57:09 +0100 Cc: Marek Zarychta , "freebsd-net@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <625E7D64-DF8C-4AEA-A7AC-AB97D617CAEF@freebsd.org> References: <18985515-e3bf-1575-4abb-30e511a45ae7@plan-b.pwste.edu.pl> <7BBAF016-3D98-40F2-9215-30E572B5857E@freebsd.org> <9EF3E6E6-E372-413E-A214-690F003AF524@freebsd.org> <41AF7F1A-CBE8-4197-852C-4B727FB1C54B@FreeBSD.org> To: Zhenlei Huang X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4Pg9Bc6zrrz4Jc2 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 20. Mar 2023, at 07:24, Zhenlei Huang wrote: >=20 >=20 >=20 >> On Mar 20, 2023, at 1:35 AM, tuexen@freebsd.org wrote: >>=20 >>> On 19. Mar 2023, at 16:59, Marek Zarychta = wrote: >>>=20 >>> W dniu 19.03.2023 o 14:42, tuexen@freebsd.org pisze: >>>>> On 19. Mar 2023, at 14:12, Marek Zarychta = wrote: >>>>>=20 >>>>> Dear subscribers of the list, >>>>>=20 >>>>> TCP algo modules can be loaded/unloaded/changed on the fly. In = FreeBSD 14-CURRENT one can even change it on an active socket with = tcpsso(8) utility, but there is no way to run jail with different TCP = stack. Neither normal nor VNET jail support switching sysctl = net.inet.tcp.functions_default. >>>>>=20 >>>>> Is there any way to set TCP algo inherited through fork+exec in a = similar way setfib(1) assigns fib or perhaps assign TCP algo per VNET = instance? >>>> Hi Marek, >>>>=20 >>>> so you are asking for the sysctl variable = net.inet.tcp.functions_default to be vnet specific? >>>=20 >>> Thanks for the reply Michael, >>>=20 >>> yes, and... not. I tend to run non-vnet jails when it's possible, so = in my case, a jail(8) parameter like exec.fib would fit better, and even = an execute helper utility, a counterpart of setfib(1) would suffice. >> Im not familiar with fibs, but the TCP stack knows about the vnet, so = the handling of the stack can >> be made vnet specific in the same way the handling of the CC module = is. >=20 >=20 > A quick look at tcp_subr.c, I think it is doable and make = `tcp_func_set_ptr` a per vnet one will be flexible enough. Yes, but we must take regarding ref counting when trying to unload a = module. But that can be done similar to the handling of CC modules. >=20 >> But I'm not sure about fibs. >> I can bring this up on the next FreeBSD transport VC and see what = others think. >=20 > As for fibs, they stand for 'forwarding information base' and are for = the routing part. > I do not think it is a proper hook point for upper layers such as TCP = in this context. Yes, this is what I also think. Will bring it up on the transport call = coming Thursday. Best regards Michael >=20 > Best regards, > Zhenlei >=20 >>=20 >> Best regards >> Michael >>>=20 >>> With kind regards >>>=20 >>> Marek >>>=20 >>>>=20 >>>> Best regards >>>> Michael >>>>> I am asking, since the almost perfect tcp_rack(4) applied on the = host is missing TCP-MD5 singing feature which is required in one of the = jails. >>>>>=20 >>>>> Cheers >>>>> --=20 >>>>> Marek Zarychta >=20 >=20 >=20 >=20