From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=dKuqABsC; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 48F095A0271 for ; Thu, 09 Apr 2026 09:41:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775720463; 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=h5414fHw37VffErI1CD4uFlQSKjy0FdfDZGFKcQkiQU=; b=dKuqABsCHjFGq3T4AKBiX3gx6lCSnCWZBNyY+EWznKXT8DjNN32AQDW/hwG5RUQ8o57rpR voEzjL7/xt66jFgfTbqHX3VKVL5h6+bFZF5fDGvC3vmyNm9xp65T6j04LThLlKD1QcxuOM AqFRvbZyHS5pv4fv7wpBU0R6ubeLkEI= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-455--FjpC36NNtWLHR9f8wsGRQ-1; Thu, 09 Apr 2026 03:41:01 -0400 X-MC-Unique: -FjpC36NNtWLHR9f8wsGRQ-1 X-Mimecast-MFC-AGG-ID: -FjpC36NNtWLHR9f8wsGRQ_1775720460 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-488a8738d96so4083315e9.2 for ; Thu, 09 Apr 2026 00:41:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775720459; x=1776325259; h=date:content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h5414fHw37VffErI1CD4uFlQSKjy0FdfDZGFKcQkiQU=; b=ERk++ejAtQ0zOj1KpXyXZK3hOgqd762/roFNQ4GYNC7P43J+qpFiWVns/gE0m7FD4X s29ILlBOC+gq5gnFLzz3xaO2dxIS9wClLTJ3M0XNjSYyQOvaWSuedZqHQf+Zn17IVpDN ALh+zBoA1WYILI/WfmkoziU14Eym4OZdnclJ0gcAfJJCO9x3LH7mwC2//6h+KNxGDKzR +gLCL3A5frcxxNi86PGYegcr35nF7V2cFCDGZP3cnef0yGmEUYwNUrOwJa5WxnUnC61Q ztP9eOW6qVhfuNSku/+JuWws+RE/leKtFU9Mo5w/DwdJIyScZmKk13aBxGkX/KuubjIH pBbQ== X-Gm-Message-State: AOJu0Yyhewj36DQF7bQ/2TDEDpaRAc0/lrAI4SSlGNnTY4HyWk6Fa/2X +2cZQCxmr/I/GBaGiQQItBdM9dmScKLl2yrHSEq6Au2P6ZQhnVMTrnZ+aJZkLkS/H1pBrhBYnR3 08S/898xNIvWPXdOuNF5eFzDHYB1Pi/Hh6KWD0IbWc0sjhNm3ZVFHJIP/tKy+zQ== X-Gm-Gg: AeBDieuqW3706mo/NK/5oy2m43y18w6Yo9iX5TF3VaVAjOo1Ar7PC76oIkUmUXVRTzr JB4tOM5uwSdjrPVqwHoI2PJ7jk3shFUxamCNa2w49ijEhI1hRvlqOerNq+dcs9f4BabkgLf2lqr 6koq070ybtbqT7ROof81DWHds4rsr4whPRx2F0VlC9QFqHwZzpRXZyj624fo9FBFAw0E3MrodAf aj+Ur7abntA6T1d7vilqs/vkrBBL5juxl3gJp2spxTZ0D7jA/vC+oPi2usb1ZMBfeY3kyXg/GUR NZWPvN5NJyH2WJn5EfKTMtfBlr/nUzawDTkYJpOGPA51Dqmj9M9PrHEWWzQoQ4tw2ookLHHuhf7 4vqFZm4W3DvDLynEjWjGvdke7PMRouYJl X-Received: by 2002:a05:600c:a08:b0:487:300:d9ca with SMTP id 5b1f17b1804b1-488998e4137mr346064785e9.31.1775720459178; Thu, 09 Apr 2026 00:40:59 -0700 (PDT) X-Received: by 2002:a05:600c:a08:b0:487:300:d9ca with SMTP id 5b1f17b1804b1-488998e4137mr346064435e9.31.1775720458687; Thu, 09 Apr 2026 00:40:58 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488cd1879b2sm26071785e9.8.2026.04.09.00.40.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Apr 2026 00:40:57 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 06/18] fwd: Better split forwarding rule specification from associated sockets Message-ID: <20260409094056.11fc12bd@elisabeth> In-Reply-To: References: <20260407031630.2457081-1-david@gibson.dropbear.id.au> <20260407031630.2457081-7-david@gibson.dropbear.id.au> <20260408011445.275ff479@elisabeth> <20260408233954.51bb5530@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Thu, 09 Apr 2026 09:40:57 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: uKo1YDULbn-3JmVC3rb7LzUVdrTj87KgDlF-Y7d4-5s_1775720460 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: H5QGVLWRME2EQCC6DU7NQWKEJR53VOF6 X-Message-ID-Hash: H5QGVLWRME2EQCC6DU7NQWKEJR53VOF6 X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 9 Apr 2026 10:47:54 +1000 David Gibson wrote: > On Wed, Apr 08, 2026 at 11:39:55PM +0200, Stefano Brivio wrote: > > On Wed, 8 Apr 2026 11:30:29 +1000 > > David Gibson wrote: > > > > > On Wed, Apr 08, 2026 at 01:14:46AM +0200, Stefano Brivio wrote: > > > > On Tue, 7 Apr 2026 13:16:18 +1000 > > > > David Gibson wrote: > > > > > > > > > 6dad076df037 ("fwd: Split forwarding rule specification from its > > > > > implementation state") created struct fwd_rule_state with a forwarding rule > > > > > plus the table of sockets used for its implementation. It turns out this > > > > > is quite awkward for sharing rule parsing code between passt and the > > > > > upcoming configuration client. > > > > > > > > Indeed, I hated it, in that short moment I had to fiddle with it. Thanks > > > > for coming up with a cleaner solution. > > > > > > Yeah, mea culpa. Seemed like a good idea at the time, but it wasn't. > > > > > > [snip] > > > > > /** > > > > > - * struct fwd_table - Table of forwarding rules (per initiating pif) > > > > > + * struct fwd_table - Forwarding state (per initiating pif) > > > > > * @count: Number of forwarding rules > > > > > * @rules: Array of forwarding rules > > > > > + * @rulesocks: Pointers to socket arrays per-rule > > > > > > > > I don't see this as particularly descriptive (which sockets? What's > > > > the array size?). I'm thinking of something like: > > > > > > > > @socks_ref: Per-rule pointers to associated @socks, @sock_count of them > > > > > > There are @count of them, not @sock_count... > > > > Oops, "of course"... > > > > > which I guess just > > > emphasises the need for a better description. How's this: > > > > > > * struct fwd_table - Forwarding state (per initiating pif) > > > * @count: Number of forwarding rules > > > * @rules: Array of forwarding rules > > > * @rulesocks: Array of @count pointers within @socks giving the start of the > > > * corresponding rule's listening sockets within the larger array > > > > "Array of @count pointers" is ambiguous in English as it might refer to > > pointers to @count. It obviously doesn't, but it might take a couple of > > readings to realise that. Simple fix: "Array of pointers (@count of > > them) ...". > > Good point. > > > For the rest, yes, it's better, but I started wondering if we could > > simplify the representation a bit by, either: > > > > 1. storing indices instead of int *, or > > We could do that, but it makes lookups of a rule's sockets more > awkward for minimal benefit I see. > > 2. storing start and end. I'm not sure if it's usable, but it would > > actually look easier to describe > > We could do that, but it means maintaining redundant information that > we never actually have a reason to consult Right... then let's just make this clear I suppose... > > if neither of these applies (I didn't really think it through), maybe > > this is slightly more intuitive: > > > > * Pointers to entry in @socks (@count of them) with first socket for each rule > > > > ? If not, I think the version you just proposed is better than the > > original and sufficiently clear anyway. > > I have this version now: > > /** > * struct fwd_table - Forwarding state (per initiating pif) > * @count: Number of forwarding rules > * @rules: Array of forwarding rules > * @rulesocks: Parallel array ro @rules (@count valid entries) of pointers to s/ro/of/ (?) > * @socks entries giving the start of the corresponding rule's > * sockets within the larger array > * @sock_count: Number of entries used in @socks (for all rules combined) > * @socks: Listening sockets for forwarding > */ > ...other than that it looks pretty clear to me. -- Stefano