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 4A7755A004E for ; Thu, 11 Jul 2024 06:26:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1720672004; bh=BGCvvlFnXMrrGf8R+JkmorEQ3Sc7K5Rbh8vwQDL8EWM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dAApVmtgnOHpKkhUBLfVO962VgCRs7Um6Z9v4fnKzdkOLuuJHRMDAvpYqcpZZ70m0 /APBGFN+x4WBY2l3PjddLLNkCX6OR40cbCV8GGaRiC/xx5btVrwCT2o6qNe81COsSk puNliQv7Bg9dOk01k/SqWqM5q4eDDBHjCE1BqAywvCVQuYtdXOr24Ba0GgSoCWHHjr +cuZ6Zr15PokoaCTG+q+QWbTxLdFKFaKLAQz7J0T4Afs+9UPkfvqbQ7jfvhfs15aJf pHf/lXxTV8zqlzbGnpchPmXz4jtjsGEK8I8a2PPozWSx8IKpAC6dDLIfEI+BJqSnqq 2vbVmwLRE4Ufg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WKMBD2SKKz4wnx; Thu, 11 Jul 2024 14:26:44 +1000 (AEST) Date: Thu, 11 Jul 2024 14:26:38 +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-1-david@gibson.dropbear.id.au> <20240705020724.3447719-21-david@gibson.dropbear.id.au> <20240710003202.2909199a@elisabeth> <20240710233503.03147137@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BUnPfWfuhJt7NsVd" Content-Disposition: inline In-Reply-To: <20240710233503.03147137@elisabeth> Message-ID-Hash: PU3G2RVPR3LPRAXVH6SKQH32QFVVLMI5 X-Message-ID-Hash: PU3G2RVPR3LPRAXVH6SKQH32QFVVLMI5 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: --BUnPfWfuhJt7NsVd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2024 at 11:35:23PM +0200, Stefano Brivio wrote: > 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: > > > Nits only, here: > > >=20 > > > On Fri, 5 Jul 2024 12:07:17 +1000 > > > David Gibson wrote: > > > > > > > [...] > > > > > > > > + * @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, uin= t8_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 this makes me > > > doubt a bit about the "forwarding" / "endpoint" choice of words. =20 > >=20 > > Heh, no, here "fside" is simply short for "flowside". Every flowside > > has both forwarding and endpoint elements. >=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 flow. > >=20 > > Hrm.. now that pif has been removed from here, maybe I could rename > > struct flowside back to 'flowaddrs' or 'sideaddrs' perhaps? >=20 > That's also confusing because it contains ports too (even though sure, > in some sense they're part of the address). Right :/. > 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? Still need a conventional name for the variables. "fap" probably isn't the best look, and still has the potentially confusing "f" in it. > 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 suggestion > 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 correctly. 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. 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 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 --BUnPfWfuhJt7NsVd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmaPXv0ACgkQzQJF27ox 2Gf9+A/+KTieXDec9NdSfoY2SK1Oe/1j1oh4aEV5kjH3Txd9+zKDUurosjHS6xb5 6KPKwvKKSKXFnJe1VCwS/zZu4lLDkg1QCDQd2/ATyr9KwXiX8VMTW18EsTPpP+Y6 j3G8zyp8jJCdG0uL7JRoQ/I9w7iNKzZj2VgZJDnlV2qwFBPuWfowHRDeMpeDjB8g w+njsEXXWM1wBXka1BzhaRhqAQSJi5Y4G1h4xAL0Dt0i1m6cUfRzQ1dD26XFZGvq GpsFmfEnrRaNnKgepUMC+MSYtrEo2eO+Oinv3QNvfAUBqLs62bRI/gOrnwUnDm48 d2sdoVjyRuOsDAvhMDttr8DQH2Ntgu2pvmUIsWslkqtjzbXWZd2ipTlpRjswtfqX mAuvtJ0bGVPqaCMmrKOUK1mrmgX6WN/Y6vZkxL4N74TbvPpbNJZa/3cUyP+XBfnt MpKzOotYjw3v/ctYleTVWLB+YMWxufYqwluL/UY74upd8JU007B505pA41dpy+wg 0wljhYyBvFVDcupQezf8I/MfuebnsOydAFQKz+60l62D11JXav4i0ULwodUPapcu 1eE0auLMvjHOBgCdCMwrQOdyTckYCnYmo4rN3bo98kHUn9i9S5YrFZjUG+rMi5KC E5H4vZR9V8EqL4X6cFN3ZjBVpSk/ddoIIEBwohdSHPDuUTDGBcs= =TFeB -----END PGP SIGNATURE----- --BUnPfWfuhJt7NsVd--