From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id BE09B5A004F for ; Mon, 15 Jul 2024 06:15:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1721016929; bh=BShQUmiTOkll6vkLViz7BpJh7L5b/LyBMeZsGruk9ak=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m+KCWAGFrWhcj3JR81Vxmr+ipQVgGPbWPOrSk1KHF200JbaoKH1+OSudEo+7gy25N MHpQmx+WTFdU4jFzpm0cNiixfwmPiC3mGTRtE+5x1JA+ne3EF/UM1ADG7Hudt9YFOn 6zG4w+zzebIOwjLM3zcyN9f0bT7SYcyTG5zlQEoreZlBa9znjIBodScxAVPgl6pArA NwTYqG3OKdCVoFvO4XE2u5qguXZbToq6nGYrxToEc/mSfdaIVd5UVlucRHfdJHkRNf drPFFFzYAUWqk1jejA9A1CGKoEDsUEeDRhX8Abun1y7O3DIs1+ll+0nEWGFEn3PdcJ qivY9N6dy4QFw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WMplP2jQYz4x1V; Mon, 15 Jul 2024 14:15:29 +1000 (AEST) Date: Mon, 15 Jul 2024 14:06:45 +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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uXSr0jGXYJhKEztd" Content-Disposition: inline In-Reply-To: <20240712102134.35e5fa2d@elisabeth> Message-ID-Hash: MN5ZOQJEQNA4YQYKXJWKSFEPAYZMNOA3 X-Message-ID-Hash: MN5ZOQJEQNA4YQYKXJWKSFEPAYZMNOA3 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: --uXSr0jGXYJhKEztd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > 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 wrote:= =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_NON= E if not found > > > > > > > > + */ > > > > > > > > +flow_sidx_t flow_lookup_sa(const struct ctx *c, uint8_t pr= oto, 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 hav= e any > > > > > > > quick fix in mind, and it's _kind of_ clear anyway, but this = makes me > > > > > > > doubt a bit about the "forwarding" / "endpoint" choice of wor= ds. =20 > > > > > >=20 > > > > > > Heh, no, here "fside" is simply short for "flowside". Every fl= owside > > > > > > 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 convention = for > > > > > > naming struct flowside variables. I'd say 'side', but sometimes > > > > > > that's used for the 1-bit integer indicating which side in a fl= ow. > > > > > >=20 > > > > > > Hrm.. now that pif has been removed from here, maybe I could re= name > > > > > > struct flowside back to 'flowaddrs' or 'sideaddrs' perhaps? = =20 > > > > >=20 > > > > > That's also confusing because it contains ports too (even though = 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 lo= ng, > > > > > 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 struggling= with > > > > > is rather 'forwarding' and 'endpoint'. I don't have any good sugg= estion > > > > > 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 cor= rectly. =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 that > > > > 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 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 than > > > "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 > 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? Yeah, that's fair. > 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. I don't really follow what you mean. > Again, I would just leave that as "forwarding" in this series, and then > change it everywhere if we come up with something nicer. Seems reasonable. It'd still be nice to have an alternative to 'fside' that doesn't have the confusing 'f'. --=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 --uXSr0jGXYJhKEztd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmaUoEYACgkQzQJF27ox 2GfzQRAAoiMW1197RCotpKaGO4yhIr8OItl6YUbFJd9SpGkQPzof7IjDHeYMoukH aUhxygLJvLv7oVuoNVM+HSiRWy91RdI3fARaAQWMHhzcH8lDkRZWrMBnr7UFfK2Q Bx1UkXRjnWbRngxs0wppFGYQ6j3poHln95jNAUu80A7Sv6ZvTAAC53aepnF2XFgD MWGVCG2DtKP+TYvD9VcAIQ21Sy72rQy81RcsDdWfC+CFyArgFHuVthtUGGIpf0ql IU+QzshLQ0gLAL+vDLTf5iWnWcBA/u1ysI7o7gs3nUa51v1v3x1D0p0DyG5b3x/l Y42GFQ4qa/ioYqZ4qNmpZJewa6hTJmBNvT0sG4DmqGLeksUA9/gH4UW5H+11eXOT wbxFXCR0stRvtgETOaSogEkJ0qzHARPTfiA9MiDx0qYoGEf+K1p94gdtJSiqWp8e cxG5w9Qnt3tfF1fHwVza+BjO1rn8nuvKLsNheWR7jtkxXQhdB3Tm3SCRMbN2xp5c dBkZktg+Zbtin3LpLeHsYA5M/w0Pmvh+WPWRI2TSBgA40LzqgtTpbGeFqxsZA6Yo 5WuHNJZPbK3As/kBToPxheHqimmH0e1jGdP49cqjSUByq8wf06WP5uEBFzgu27Nk hqlpt1tN+tFmR06IO+FDWyGUFnoMj1V83o5o2P3AQ0LV4M32D/0= =urtr -----END PGP SIGNATURE----- --uXSr0jGXYJhKEztd--