From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTP id 0144E5A004E for ; Mon, 15 Jul 2024 18:38:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721061499; 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=MBaXANCXKVGJz/jAKEZxM+yVfnpHePO307HaSyeEFIU=; b=XFKjSBch7HVn/49qz3Ba/26EeljImJWyoeoGi4TYnewZ9rmQowxRmKzUmK70d2IjV3gI9/ MRC8yO+GZW5UDFsAv9SxEkAF07LyN3GGip8u9TlFwTEuuz7ZjSc49UkPgqz5Knspg3Y2bJ M+GPfI+XciWjUwDGTwxdJ1k5xBY0mZY= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-644-CR1AsIePOOyB1t9J0QRpcw-1; Mon, 15 Jul 2024 12:38:17 -0400 X-MC-Unique: CR1AsIePOOyB1t9J0QRpcw-1 Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6b5e6b47504so61521406d6.1 for ; Mon, 15 Jul 2024 09:38:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721061495; x=1721666295; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eqAJIgR/C68shHOcHxDQ8SwWpp67xpkCIHbTy3ZYjwQ=; b=UYH7jDAdmIKC3CNwiJFmKfRxJ55vQoLN2u+0GP6FYlu1SnZlJkh8ci/lqnboHwk5ul oYNYB+GsQVlXpH5cjeVdy+acBZsASmMF9ILQXsNGWbumujSI2pz/z9dylgGj4XKkQtuX 0tzU+vn1M68imBK+NaOiv5mrRBV7pDIaXhuCFwKKtcd7MIvJo6Utq/aLVjDaUSiJBRHE NpHtOQBXXW9MHOymWE6jwGpnZ+oWg9AWy2bLuOF0bGltm1bRez9F43GxMvuoii0GQtVT jLFeI4ToupOW71SBfuJxsBKPqDlDmpHGSW6m8jH2Llqy6a2S61aylPNs4Pa8BjtLfUew JwQw== X-Gm-Message-State: AOJu0YzgJvuwaQyB75FWYWINuJu19tup72HVoShqm6vNTWs/Qx39PpEt yAgW0sqsXI0PXE4phuF3BRgFInUk9/Llbfgg/BmhfHfb16r/zR8V1xJYJpqvLqPKH0liLfDZ6km CttrrPAz7DnsLpj9ecXrLmmABONvooykb6jZyLwAZgq/08a07OKu1M7Gdi086 X-Received: by 2002:a05:6214:29e1:b0:6b4:ffc9:1e9e with SMTP id 6a1803df08f44-6b77de619a4mr3050786d6.3.1721061494951; Mon, 15 Jul 2024 09:38:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGSPPyoTMbEBzMvi/rhbvR9MWkYVldWRMJ2gESH3vMVCivq/dImDfr7o2byLu0o06995vgsYA== X-Received: by 2002:a05:6214:29e1:b0:6b4:ffc9:1e9e with SMTP id 6a1803df08f44-6b77de619a4mr3050586d6.3.1721061494567; Mon, 15 Jul 2024 09:38:14 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b76194f5b7sm22712216d6.9.2024.07.15.09.38.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2024 09:38:13 -0700 (PDT) Date: Mon, 15 Jul 2024 18:37:39 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v7 20/27] udp: Create flows for datagrams from originating sockets Message-ID: <20240715183731.70eda3db@elisabeth> In-Reply-To: References: <20240705020724.3447719-21-david@gibson.dropbear.id.au> <20240710003202.2909199a@elisabeth> <20240710233503.03147137@elisabeth> <20240711101937.2f7fb626@elisabeth> <20240712102134.35e5fa2d@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 62AARY6INFGQYO3NC7MFZEX5SHPPAJOS X-Message-ID-Hash: 62AARY6INFGQYO3NC7MFZEX5SHPPAJOS 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, jmaloy@redhat.com 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 Mon, 15 Jul 2024 14:06:45 +1000 David Gibson wrote: > On Fri, Jul 12, 2024 at 10:21:41AM +0200, Stefano Brivio wrote: > > On Fri, 12 Jul 2024 08:58:57 +1000 > > David Gibson wrote: > > =20 > > > On Thu, Jul 11, 2024 at 10:20:01AM +0200, Stefano Brivio wrote: =20 > > > > On Thu, 11 Jul 2024 14:26:38 +1000 > > > > David Gibson wrote: > > > > =20 > > > > > On Wed, Jul 10, 2024 at 11:35:23PM +0200, Stefano Brivio wrote: = =20 > > > > > > On Wed, 10 Jul 2024 09:59:08 +1000 > > > > > > David Gibson wrote: > > > > > > =20 > > > > > > > On Wed, Jul 10, 2024 at 12:32:02AM +0200, Stefano Brivio wrot= e: =20 > > > > > > > > Nits only, here: > > > > > > > >=20 > > > > > > > > On Fri, 5 Jul 2024 12:07:17 +1000 > > > > > > > > David Gibson wrote: > > > > > > > > =20 > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > + * @c:=09=09Execution context > > > > > > > > > + * @proto:=09Protocol of the flow (IP L4 protocol number= ) > > > > > > > > > + * @pif:=09Interface of the flow > > > > > > > > > + * @esa:=09Socket address of the endpoint > > > > > > > > > + * @fport:=09Forwarding port number > > > > > > > > > + * > > > > > > > > > + * Return: sidx of the matching flow & side, FLOW_SIDX_N= ONE if not found > > > > > > > > > + */ > > > > > > > > > +flow_sidx_t flow_lookup_sa(const struct ctx *c, uint8_t = proto, uint8_t pif, > > > > > > > > > +=09=09=09 const void *esa, in_port_t fport) > > > > > > > > > +{ > > > > > > > > > +=09struct flowside fside =3D { =20 > > > > > > > >=20 > > > > > > > > And the "f" in "fside" stands for "forwarding"... I don't h= ave any > > > > > > > > quick fix in mind, and it's _kind of_ clear anyway, but thi= s makes me > > > > > > > > doubt a bit about the "forwarding" / "endpoint" choice of w= ords. =20 > > > > > > >=20 > > > > > > > Heh, no, here "fside" is simply short for "flowside". Every = flowside > > > > > > > has both forwarding and endpoint elements. =20 > > > > > >=20 > > > > > > Oh, I thought you called it fside here because you're setting t= he > > > > > > forwarding part of it directly, or something like that. > > > > > > =20 > > > > > > > So it is confusing, but > > > > > > > for a different reason. I need to find a different conventio= n for > > > > > > > naming struct flowside variables. I'd say 'side', but someti= mes > > > > > > > that's used for the 1-bit integer indicating which side in a = flow. > > > > > > >=20 > > > > > > > Hrm.. now that pif has been removed from here, maybe I could = rename > > > > > > > struct flowside back to 'flowaddrs' or 'sideaddrs' perhaps? = =20 > > > > > >=20 > > > > > > That's also confusing because it contains ports too (even thoug= h sure, > > > > > > in some sense they're part of the address). =20 > > > > >=20 > > > > > Right :/. > > > > > =20 > > > > > > I would suggest keeping it > > > > > > like it is in for this series, but after that, if it's not too = long, > > > > > > what about flow_addrs_ports? =20 > > > > >=20 > > > > > Still need a conventional name for the variables. "fap" probably > > > > > isn't the best look, and still has the potentially confusing "f" = in > > > > > it. > > > > > =20 > > > > > > Actually, I don't think flowside is that bad. What I'm struggli= ng with > > > > > > is rather 'forwarding' and 'endpoint'. I don't have any good su= ggestion > > > > > > at the moment, anyway. Using 'local' and 'remote' (laddr/lport, > > > > > > raddr/rport) would be clearer to me and avoid the conflict with= 'f' of > > > > > > flowside, but you had good reasons to avoid that, if I recall c= orrectly. =20 > > > > >=20 > > > > > Kind of, yeah. Local and remote are great when it's clear we're > > > > > talking specifically from the point of view of the passt process. > > > > > There are a bunch of cases where it's not necessarily obvious if = we're > > > > > talking from that point of view, the point of view of the guest, = or > > > > > the point of view of the host (the last usually when the endpoint= is > > > > > somewhere on an entirely different system). I wanted something t= hat > > > > > wherever we were talking about it is specifically relative to the > > > > > passt process itself. > > > > >=20 > > > > > I get the impression that "forwarding" is causing more trouble he= re > > > > > than "endpoint". "midpoint address"? "intercepted address"? > > > > > "redirected address" (probably not, that's 'r' like remote but th= is > > > > > would be the local address)? =20 > > > >=20 > > > > I think "forwarding" is still better than any of those. Perhaps "pa= sst > > > > address" (and paddr/pport)... but I'm not sure it's much better tha= n > > > > "forwarding". =20 > > >=20 > > > Hm. "passthrough address"? Kind of means the same thing as > > > "forwarding" in context, and maybe evokes the idea that this is the > > > address that passt itself owns? =20 > >=20 > > I'd still prefer "forwarding" to that... at least I almost got used to > > it, "passthrough" is even more confusing because not everything really > > passes... through? =20 >=20 > Yeah, that's fair. >=20 > > The part I'm missing (with any of those) is "here" vs. "there", that > > is, a reference to the "where" and to the topology instead of what that > > side does. =20 >=20 > I don't really follow what you mean. What makes "forwarding" and "passthrough" not so obvious to me is that they don't carry the information of _where_ in the network diagram the side is (such as "local" and "remote" would do), but rather what it does ("forward packets", "pass data through"). >From passt and pasta's perspective, the "forwarding" side could be called the "here" side, and the endpoint could be called the "there" side. Those names are not great for other reasons though, just think of the sentence "there is the 'there' side and the 'here' side", or "here we deal with the 'there' side". So at the moment I don't have any better suggestion in that sense. Telecommunication standards frequently use "near end" and "far end", but I guess you would still have a similar issue as with local/remote, and also "far" starts with "f". > > Again, I would just leave that as "forwarding" in this series, and then > > change it everywhere if we come up with something nicer. =20 >=20 > Seems reasonable. It'd still be nice to have an alternative to > 'fside' that doesn't have the confusing 'f'. --=20 Stefano