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=HaYyjMdU; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id E0F4A5A0265 for ; Wed, 08 Apr 2026 23:40:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775684399; 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=w48beqzdJ12Oqg07Dv+d5+7lYjFl8yzuGFF4pE+Z2Lk=; b=HaYyjMdUesjTe734zfPBuyzeC+r/rpur/BqmseG0xlItDicolBOpXl484O8ZF/TMEywDBS s0ABzYg3xpTnY95iaeXfzluwrWEz8HEx0/QBS6qNhLmQ2Ylqj62TvJf5UhQIIjIPyYsv1O J9Yf/c1mJCRjLEZ4v7wLwowiDnzviqA= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-646-W6AHHG3KN8aoALqaq6XF3Q-1; Wed, 08 Apr 2026 17:39:58 -0400 X-MC-Unique: W6AHHG3KN8aoALqaq6XF3Q-1 X-Mimecast-MFC-AGG-ID: W6AHHG3KN8aoALqaq6XF3Q_1775684397 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-488c74405ecso926435e9.1 for ; Wed, 08 Apr 2026 14:39:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775684397; x=1776289197; 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=w48beqzdJ12Oqg07Dv+d5+7lYjFl8yzuGFF4pE+Z2Lk=; b=EjWrM9LoPX9V5ByU5tgHpx9uSDm2IHiidd23ykI1accA1YbOjP2riDJnblw5cvILbn J10XvEJACW03DhxJoC3uDavsHTDifYITwOPKnjgp5TfVqGoWqEjmVOfK4iGHRQ6c56LE uQOjngJco9tgFN/5dlVOYLTsjtqdCj+gMs5PFo7y7gC4mnJnBxqBqSEsjUjHzUUOGKCi nQ9sEJc1buoePZvfrpRI7YdavKIAH/ap/PmY4NTUcjzmq80X+msfMR+GUTagzvklIYmT wy7dkKPeKKoz60tCNC5KLBxyUDRKhw7eFdfvvPmzezg3ebBei9W7sKsePno7Zlvj0Uq+ mO5g== X-Gm-Message-State: AOJu0Ywfv4n5+sz/ZQsb1k41RbiJlLMKUisuGxLeuHq4Zr/Om6W7YoE6 BkZpEM9tegtkBn0ofw0QZM0Jh+k5ZubxsjyXVgTXqTEnECU38we3EryuQGjmQZj8HRahCnKj18s XQ/KeICKypUS60r0hwCaK7rX3dk+2Juh9vZ5KK7iHZompobGkHXj8yA== X-Gm-Gg: AeBDieuJTvN3yX1RzlhJuQNxxMbghTng/hsxV/VRa1N9KLBDGrdie9tzAGD4jctusgX 90egIATbyoVVENORsbtSqCKIMQfRASx15dG0+nVNwFdTbw+adZVh6liwRUmbRqNCH6swIbQ07Hg ciyDF1XbEy679SNVtc0BSx8mXoegBSKrmC83wNei89bvX920c7Q6t+wgecHfzRJNyuV1p7D9l/O Wa9iq0dWotHITnsJYZ7Ir8TNOGP9ZqqwzE7ji9ZFXqOkp6AQgxI09K4ZyqMDGXGqLb239Ajcp4l JHWRP/PdDknvst9mEv/1H4unbhOKO1cPu0Ugq5IHx/o/4HeAkDbkRfirnUyl+BBBQqtK+q1MSSo UAB3soIxNEJP7s8hR69XPtv2eOm/Xal4j X-Received: by 2002:a05:600c:c056:b0:488:8b99:54a1 with SMTP id 5b1f17b1804b1-488998f14d5mr220575515e9.28.1775684397170; Wed, 08 Apr 2026 14:39:57 -0700 (PDT) X-Received: by 2002:a05:600c:c056:b0:488:8b99:54a1 with SMTP id 5b1f17b1804b1-488998f14d5mr220575325e9.28.1775684396632; Wed, 08 Apr 2026 14:39:56 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488cd21b604sm19737465e9.10.2026.04.08.14.39.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2026 14:39:55 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 06/18] fwd: Better split forwarding rule specification from associated sockets Message-ID: <20260408233954.51bb5530@elisabeth> In-Reply-To: References: <20260407031630.2457081-1-david@gibson.dropbear.id.au> <20260407031630.2457081-7-david@gibson.dropbear.id.au> <20260408011445.275ff479@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: Wed, 08 Apr 2026 23:39:55 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 6ZxcnjZVEyn3hTQx31pKqm6EMhqK-fg550W-NdD1L3E_1775684397 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: FV6NSDAJX2SQAGRAZ5XICJBMNDWNEC7I X-Message-ID-Hash: FV6NSDAJX2SQAGRAZ5XICJBMNDWNEC7I 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 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) ...". 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 2. storing start and end. I'm not sure if it's usable, but it would actually look easier to describe 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. > * @sock_count: Number of entries used in @socks (for all rules combined) > * @socks: Listening sockets for forwarding > > > > * @sock_count: Number of entries used in @socks > > > * @socks: Listening sockets for forwarding > > > */ > > > struct fwd_table { > > > unsigned count; > > > - struct fwd_rule_state rules[MAX_FWD_RULES]; > > > + struct fwd_rule rules[MAX_FWD_RULES]; > > > + int *rulesocks[MAX_FWD_RULES]; > > > unsigned sock_count; > > > int socks[MAX_LISTEN_SOCKS]; > > > }; > > > > -- > > Stefano > > > -- Stefano