On Thu, 11 Jul 2024 14:26:38 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:
On Wed, Jul 10, 2024 at 11:35:23PM +0200, Stefano
Brivio wrote:
On Wed, 10 Jul 2024 09:59:08 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:
On Wed, Jul 10, 2024 at 12:32:02AM +0200, Stefano
Brivio wrote:
> Nits only, here:
>
> On Fri, 5 Jul 2024 12:07:17 +1000
> David Gibson <david(a)gibson.dropbear.id.au> 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, uint8_t pif,
> > + const void *esa, in_port_t fport)
> > +{
> > + struct flowside fside = {
>
> 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.
Heh, no, here "fside" is simply short for "flowside". Every
flowside
has both forwarding and endpoint elements.
Oh, I thought you called it fside here because you're setting the
forwarding part of it directly, or something like that.
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.
Hrm.. now that pif has been removed from here, maybe I could rename
struct flowside back to 'flowaddrs' or 'sideaddrs' perhaps?
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)?
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".