From nobody Sat Oct 18 08:37:00 2025 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 4cpZmw65BZz6Cl4c for ; Sat, 18 Oct 2025 08:37:04 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cpZmw41GNz3sWF; Sat, 18 Oct 2025 08:37:04 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1760776624; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NVUK8KuyGruB0SlBtdJA+H0tb/RY+0KTwtZErBchcAg=; b=iCbOCd0xNVp6jETo/yVtTul5Fm+8IWPcgzBR9zZHLu2Hm3koT0N2FF1oFuD4/JGXF7uAmb PR9e+0WZl/Kv1mVNEKDcxmKDRDGBTxbK5ksgBYjF4Q+322kdW2R69t+EbiSWAcBO6+lEVx MUtAA0yDrXozNZbBtJCQ8DzUK7hEfzonQ+e5I1e4qvhw/U/9VO3z13WgFSNz3oeULgRI+B LQ0mt/qmsLG9UZNFEffRfz+S/ZfuWBA52PkLlYXJXNXj9xZKHhGGGpW0Ucc8jwxK+GEmvo KYo9McTshWOLUvjLGKKqGp+PNn/0sPlgVwACk1Okr0ZoYzn8mQCrgr08YlMUZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1760776624; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NVUK8KuyGruB0SlBtdJA+H0tb/RY+0KTwtZErBchcAg=; b=D0F5JscQgACpCc8kpJ3HouZ+2QDwS05/YepyKNi6gz+n+3efrhmjiym8pTUgPZXnnn83+9 c/rG7jngCAYNDm7D/VEBeE06NViG2hpbVixTdbXqAF8XdhLctmLFZcYiXfkk5fnAPd20Uy Vuy9lVbhHkx2DEyhMlCBdlxfYEHPbXchFo6CFzc2FxcmlTgpLTxKgwRI9h5nhENvM85w1Y zbFEK7o1M/Y27t3Ia57B+2THTcDZTiaJIuodL76V+IT2zjd1n7ORBTBejagKMhBllxa3vr QAbMMNezPuQKob26MGfVgf4OdejnKlnu5POx2nUJFay63MRBRq9mWBoBEKgv0A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1760776624; a=rsa-sha256; cv=none; b=JrataMAF2TVpkDo9TTtpXkwDO0MbaQq9bMHGcQlEa9lcXOu3D2nvxe94IzMEK8wpv5hSco aQaqpLpvQuzbyofnlJGJDOdS1LET9CB9HU9UIKw9PaxIzHlEL0meWlDQJm1Y/j50AD5Vly z7ijU7qJZUa7HYdq6ruGJWEywH72OAwDJfyNk7JDI7gWV2XPyYOHfmp1FauH2T8W3RWZJ3 sujcwVbL2RRk14Z3LDUUtzpPG10Llv/NP2ZDDVsDljR819y077WcFXL4nCsgIBkoNhjqck yK/hwAYeQ5om0eRBilyVZafZ770xhla8vhdTgBxvN1qDuPD3l5fFsypxsOvOug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cpZmw27BFzwBM; Sat, 18 Oct 2025 08:37:04 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 5215E1D081; Sat, 18 Oct 2025 10:37:01 +0200 (CEST) From: Kristof Provost To: Vadim Goncharov Cc: Seyed Pouria Mousavizadeh Tehrani , freebsd-net@freebsd.org Subject: Re: Support for nv(9) in if_clone Date: Sat, 18 Oct 2025 10:37:00 +0200 X-Mailer: MailMate (2.0r6272) Message-ID: <7AA688F9-8DB6-41F0-AE57-B52123BE80BB@FreeBSD.org> In-Reply-To: <20251016235601.2e79e2f7@nuclight.lan> References: <64262fc7-2c29-4749-94dc-1de2b464f270@spmzt.net> <20251016235601.2e79e2f7@nuclight.lan> 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 Content-Type: multipart/alternative; boundary="=_MailMate_F16E4F54-FBEF-4CB4-AC32-9CC5AAFDEE57_=" Content-Transfer-Encoding: 8bit --=_MailMate_F16E4F54-FBEF-4CB4-AC32-9CC5AAFDEE57_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 16 Oct 2025, at 22:56, Vadim Goncharov wrote: > On Wed, 15 Oct 2025 11:15:03 +0330 > Seyed Pouria Mousavizadeh Tehrani wrote: > >> Currently our ifreq interface supports nv(9) lists via ifreq_nv_req. >> This allows network interface drivers to implement their >> configuration >> using nvlists (for example: if_ovpn, if_pf*). >> >> There is a problem: an interface that is implemented entirely via >> nv(9) >> cannot be configured during the cloning phase (via if_clone_create). >> if_clone_create converts the ifreq struct to ifdrv and only copies >> ifr_data to params, so the ifru_nv field is lost during cloning. >> >> I am interested in implementing a solution to this issue and am >> considering two possible approaches: >> >> 1. Extend the ifdrv struct to include the ifreq_nv_req struct, and >> verify/make sure that other implemented modules are not affected. >> 2. Introduce a new ioctl, SIOCIFCREATENV, to handle the nv part >> separately, which would be more complicated but potentially less >> disruptive to existing modules. >> >> Which one do you think would be more suitable, or do you have any >> alternative suggestions? > > I'd vote for the latter, because it also will make task easier > when/if/ever > the nvlist plague will be replaced by something more sane. > Absent detail this isn’t particularly useful feedback. Having used nvlists in pf I’ve found them to be fairly useful in defining extensible interfaces. There are a few downsides though. The big one being horrendous performance and memory use for large requests. This likely isn’t a problem for this use case. It really only bit pf for state export, which is potentially very large. The other downside, and the reason I’d be inclined to look at just transitioning entirely to netlink is that dealing with them is annoying, because you have to cope with three sizes: the size of the nvlist passed from userspace, the size of the buffer userspace allocated and the size of the kernel’s reply (if applicable). It also leaves userspace to deal with ‘Is this buffer large enough?’, which isn’t really something you have to think about with netlink. As an aside, because you mention if_ovpn: I wound up using nvlists because netlink wasn’t available yet for FreeBSD. The Linux equivalent uses netlink (of course), and it would have been very nice to be able to have the same interface on Linux and FreeBSD. Best regards, Kristof --=_MailMate_F16E4F54-FBEF-4CB4-AC32-9CC5AAFDEE57_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 16 Oct 2025, at 22:56, Vadim Goncharov wrote:

On Wed, 15 Oct 2025 11:15:03 +0330
Seyed Pouria Mousavizadeh Tehrani info@= spmzt.net wrote:

Currently our ifreq interface supports nv(9) lists via if= req_nv_req.
This allows network interface drivers to implement their configuration using nvlists (for example: if_ovpn, if_pf*).

There is a problem: an interface that is implemented enti= rely via nv(9)
cannot be configured during the cloning phase (via if_clone_create).
if_clone_create converts the ifreq struct to ifdrv and only copies
ifr_data to params, so the ifru_nv field is lost during cloning.

I am interested in implementing a solution to this issue = and am
considering two possible approaches:

  1. Extend the ifdrv struct to include the ifreq_nv_req struct, and
    verify/make sure that other implemented modules are not affected.
  2. Introduce a new ioctl, SIOCIFCREATENV, to handle the nv part
    separately, which would be more complicated but potentially less
    disruptive to existing modules.

Which one do you think would be more suitable, or do you = have any
alternative suggestions?

I'd vote for the latter, because it also will make task e= asier when/if/ever
the nvlist plague will be replaced by something more sane.

Absent detail this isn=E2=80=99t particularly useful feed= back.

Having used nvlists in pf I=E2=80=99ve found them to be f= airly useful in defining extensible interfaces.
There are a few downsides though. The big one being horrendous performanc= e and memory use for large requests. This likely isn=E2=80=99t a problem = for this use case. It really only bit pf for state export, which is poten= tially very large.

The other downside, and the reason I=E2=80=99d be incline= d to look at just transitioning entirely to netlink is that dealing with = them is annoying, because you have to cope with three sizes: the size of = the nvlist passed from userspace, the size of the buffer userspace alloca= ted and the size of the kernel=E2=80=99s reply (if applicable). It also l= eaves userspace to deal with =E2=80=98Is this buffer large enough?=E2=80=99= , which isn=E2=80=99t really something you have to think about with netli= nk.

As an aside, because you mention if_ovpn: I wound up usin= g nvlists because netlink wasn=E2=80=99t available yet for FreeBSD. The L= inux equivalent uses netlink (of course), and it would have been very nic= e to be able to have the same interface on Linux and FreeBSD.

Best regards,
Kristof

--=_MailMate_F16E4F54-FBEF-4CB4-AC32-9CC5AAFDEE57_=--