From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id BCFDC5A004F for ; Wed, 17 Jul 2024 02:49:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1721177394; bh=X1s5i1tcp9njOBgs/WyE1SdwCxiZC1YpWdZ/Zn7lwAI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A7T7AEejGzP/F55sWNb6rqWjbRus9JMnSSROe9iEPIR3GGCl+tlGUnhtkOCFQUYr8 OI81DDFCsR7JSOMDO8nmwoIQzPq6eH7KWWdiDmezRXb+Sgw3HPN1r5vBWj3hDd/INX zpGWD6uOvfyDU3Kexukge+by0RA5rMUP7kckKfdCSeF8yyMeWpJbl0CsF+YmPRLLON R7DSalmSArVym2RG4paPr9+Y9i11/uN0PRWWkq8Lm6H1kbIv3DlGt7JTiWlx4/hyP/ g3dOqyxTed57jV0bPdvG3owzNJm9uxfp8c2usfWKzkfWCJ7GXzaZoXOBMPqrf4qS7r teKqt7kDyFtlw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WNy5G37nLz4x0C; Wed, 17 Jul 2024 10:49:54 +1000 (AEST) Date: Wed, 17 Jul 2024 10:49:47 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v7 20/27] udp: Create flows for datagrams from originating sockets Message-ID: References: <20240705020724.3447719-21-david@gibson.dropbear.id.au> <20240710003202.2909199a@elisabeth> <20240710233503.03147137@elisabeth> <20240711101937.2f7fb626@elisabeth> <20240712102134.35e5fa2d@elisabeth> <20240715183731.70eda3db@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XGTCx1j6rcfizAJ2" Content-Disposition: inline In-Reply-To: <20240715183731.70eda3db@elisabeth> Message-ID-Hash: P5CZPDQW26VCDOMG5CA5KPGKHH7XOA7Z X-Message-ID-Hash: P5CZPDQW26VCDOMG5CA5KPGKHH7XOA7Z X-MailFrom: dgibson@gandalf.ozlabs.org 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: --XGTCx1j6rcfizAJ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2024 at 06:37:39PM +0200, Stefano Brivio wrote: > On Mon, 15 Jul 2024 14:06:45 +1000 > David Gibson wrote: >=20 > > 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 wr= ote: =20 > > > > > > > > > Nits only, here: > > > > > > > > >=20 > > > > > > > > > On Fri, 5 Jul 2024 12:07:17 +1000 > > > > > > > > > David Gibson wrote: > > > > > > > > > =20 > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > + * @c: Execution context > > > > > > > > > > + * @proto: Protocol of the flow (IP L4 protocol number) > > > > > > > > > > + * @pif: Interface of the flow > > > > > > > > > > + * @esa: Socket address of the endpoint > > > > > > > > > > + * @fport: Forwarding port number > > > > > > > > > > + * > > > > > > > > > > + * Return: sidx of the matching flow & side, FLOW_SIDX= _NONE if not found > > > > > > > > > > + */ > > > > > > > > > > +flow_sidx_t flow_lookup_sa(const struct ctx *c, uint8_= t proto, uint8_t pif, > > > > > > > > > > + const void *esa, in_port_t fport) > > > > > > > > > > +{ > > > > > > > > > > + struct flowside fside =3D { =20 > > > > > > > > >=20 > > > > > > > > > And the "f" in "fside" stands for "forwarding"... I don't= have any > > > > > > > > > quick fix in mind, and it's _kind of_ clear anyway, but t= his makes me > > > > > > > > > doubt a bit about the "forwarding" / "endpoint" choice of= words. =20 > > > > > > > >=20 > > > > > > > > Heh, no, here "fside" is simply short for "flowside". Ever= y flowside > > > > > > > > has both forwarding and endpoint elements. =20 > > > > > > >=20 > > > > > > > Oh, I thought you called it fside here because you're setting= the > > > > > > > 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 convent= ion for > > > > > > > > naming struct flowside variables. I'd say 'side', but some= times > > > > > > > > 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 coul= d rename > > > > > > > > struct flowside back to 'flowaddrs' or 'sideaddrs' perhaps?= =20 > > > > > > >=20 > > > > > > > That's also confusing because it contains ports too (even tho= ugh 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 to= o long, > > > > > > > what about flow_addrs_ports? =20 > > > > > >=20 > > > > > > Still need a conventional name for the variables. "fap" probab= ly > > > > > > 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 strugg= ling with > > > > > > > is rather 'forwarding' and 'endpoint'. I don't have any good = suggestion > > > > > > > at the moment, anyway. Using 'local' and 'remote' (laddr/lpor= t, > > > > > > > raddr/rport) would be clearer to me and avoid the conflict wi= th 'f' of > > > > > > > flowside, but you had good reasons to avoid that, if I recall= correctly. =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 proces= s. > > > > > > There are a bunch of cases where it's not necessarily obvious i= f 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 endpoi= nt is > > > > > > somewhere on an entirely different system). I wanted something= that > > > > > > wherever we were talking about it is specifically relative to t= he > > > > > > passt process itself. > > > > > >=20 > > > > > > I get the impression that "forwarding" is causing more trouble = here > > > > > > than "endpoint". "midpoint address"? "intercepted address"? > > > > > > "redirected address" (probably not, that's 'r' like remote but = this > > > > > > would be the local address)? =20 > > > > >=20 > > > > > I think "forwarding" is still better than any of those. Perhaps "= passt > > > > > address" (and paddr/pport)... but I'm not sure it's much better t= han > > > > > "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 th= at > > > side does. =20 > >=20 > > I don't really follow what you mean. >=20 > 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"). Ah, I see. Fwiw, the reasoning here is that these are the addresses that belong to the thing doing the forwarding - i.e. passt/pasta. > >From passt and pasta's perspective, the "forwarding" side could be > called the "here" side, and the endpoint could be called the "there" > side. >=20 > 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. And in addition to that they share the problem with local/remote and near end/far end that they only make sense if your frame of reference is already passt/pasta's perspective. > 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". If we're going to assume we're talking from the perspective of the passt/pasta process, I don't think we'll do better than "local" and "remote". What I was aiming for with "forwarding" and "passthrough" was something unambiguous from "whole system" view encompassing the guest, the other endpoint and passt in between. Maybe that's not worth it, and we would be better with "local" and "remote", and add extra verbiage in the cases where it might seem like we're talking from the guest's view. > > > Again, I would just leave that as "forwarding" in this series, and th= en > > > 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 --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --XGTCx1j6rcfizAJ2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmaXFSoACgkQzQJF27ox 2GcvQhAAgcgvb8doa+XdZILgHy8JnX94HGEJGCp+y8lAyFhEgRWOt5KK7Sq+vGNp +FdqmQRQ6gAkGFAORkq2PN/uq2/0DTQawPc4KWEktlyFFGs0msowqsBTtApKGFC9 fIaejXAt72J4dRKfMD4UAWqYNTb8c0cz16dRteor8sUSBN51+IdBvbKzvKvuDjwI /UH7eiPsoU7ffF+0+pn2UHORw6hhyJo7d2goNNuRzFpuEcD2yBSRQYFeA/eG+vg7 MAnH7r6BM0vPr/hQoc7Rm5dVYE/BJTQeTOfnYN+eNZpKMy0zK4JzLOi9ja3cZgWT 8Ii5vXg8x3DdBmtxWgD8UPGijOrtTqam82I7SxQKMHULPmba1yd9FgxE7W9bGzFR Ul/eYJXMWAS4LO/FqhqV+G0KRWY84s2tuZbwT9xl0G65W/OkoK76Kgsfrh6QsTkY m5Naw9TxzcI39nECHrNieaxO0cJSnO530oIm1OA3nOVUgAhZW/lyZkM1udPAyVwZ lxj1/QfJpJOzKCWz0O4fI9+ewQ9PDFj6/2cBgyvfozCNkZEea6CK9OBzNhKkr5i2 QLaYLaUoOPLA+sThC5bA11AjQcbahbcq2OjUOn8uOn+33Jf31XCxbYHHpCzRoSLi lrRPQo6/RNuQ0+sMtxbyJ02B3F4gIOyvqVDLdZLLev04Bcgb33Y= =ElQ9 -----END PGP SIGNATURE----- --XGTCx1j6rcfizAJ2--