From nobody Tue Oct 12 11:18:35 2021 X-Original-To: freebsd-arch@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 9013F17EF1C4 for ; Tue, 12 Oct 2021 11:18:43 +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 4HTCpW13b1z4tmv; Tue, 12 Oct 2021 11:18:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19CBIZjO079528 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Oct 2021 14:18:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19CBIZjO079528 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19CBIZQt079527; Tue, 12 Oct 2021 14:18:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Oct 2021 14:18:35 +0300 From: Konstantin Belousov To: Hans Petter Selasky Cc: John Baldwin , "freebsd-arch@freebsd.org" Subject: Re: ifp->if_capabilities needs to grow Message-ID: References: <772886ef-71e9-1096-b991-a0d1dbba2ba1@selasky.org> <35447c40-a939-820f-446c-f3a1c69eadc5@FreeBSD.org> <5254ef46-e158-ef58-05eb-3d85c04a7612@selasky.org> <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <206cc4d8-6f69-8f94-b8d6-cf92d71bd28d@selasky.org> 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=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HTCpW13b1z4tmv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 12, 2021 at 01:14:06PM +0200, Hans Petter Selasky wrote: > Hi Konstantin, > > It took 20 years to reach ifcap2 . Can we assume that it will take another > 20 years to reach ifcap3 ? As John noted, we are accelerating the process. Besides TLS RX, we might have something like IPSEC_INLINE soon. As for inline IPSEC, we need to communicate the set of supported algorithms, which would require additional ioctl unless we switch (add advanced version of) CAP to use something more flexible. > > --HPS > > On 10/12/21 12:43 PM, Konstantin Belousov wrote: > > On Tue, Oct 12, 2021 at 11:20:11AM +0200, Hans Petter Selasky wrote: > > > Hi John, Konstantin and Gleb, > > > > > > There are basically three ways to solve the problem with adding TLSRX4 and > > > TLSRX6 capability bits. > > > > > > 1) Konstantin proposes to merge the API to nvlists. > > To make it clear. I do not propose to remove old ioctls. > > Just that in parallel to old way, a new nvlist-based ioctl would be added > > that has no limitation on the number of supported capabilities, by design. > > Old ifconfig continues to work, same as in scheme with XXXCAP2, but it > > kind of guarantees that we would not need XXXCAP3 ever. > > > > > > > > 2) John proposes to duplicate XXXCAP into XXXCAP2 to handle the new > > > capabilities. > > > > > > 3) Gleb proposes to free up existing bits. > > > > > > Looking at the different proposals I think John has the best one with > > > regards to MFC'ing. Then we don't change the meaning of any bits, and the > > > old ifconfig still works as expected. > > > > > > It's trivial to add a XXXCAP2 to ifconfig from what I can see. It already > > > modifying bit by bit, so no optimisations in there anyways. > > > > > > Do we have consensus? > > > > > > --HPS > > > > > > On 10/11/21 7:10 PM, John Baldwin wrote: > > > > One option is to perhaps add 'if_cap*2' with IFCAP2_* bits.  It would > > > > be MFC'able (just add the new words at the end in the MFC), it's just a > > > > bit ugly compared to having an array.  The other question is how to manage > > > > the ioctl.  Right now the ioctl is an ifreq which takes a pair of ints > > > > (if_reqcap and if_curcap).  If we use 'if_cap*2' then we can just add > > > > SIOCGIFCAP2 and SIOCSIFCAP2 to get/set the second words.  We have done > > > > this with other fields (e.g. p_flag2). > > > > >