public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: passt-dev@passt.top, jmaloy@redhat.com
Subject: Re: [PATCH v7 20/27] udp: Create flows for datagrams from originating sockets
Date: Wed, 17 Jul 2024 10:49:47 +1000	[thread overview]
Message-ID: <ZpcVKxfS3MjTLQ8p@zatzit> (raw)
In-Reply-To: <20240715183731.70eda3db@elisabeth>

[-- Attachment #1: Type: text/plain, Size: 7871 bytes --]

On Mon, Jul 15, 2024 at 06:37:39PM +0200, Stefano Brivio wrote:
> On Mon, 15 Jul 2024 14:06:45 +1000
> David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > On Thu, Jul 11, 2024 at 10:20:01AM +0200, Stefano Brivio wrote:  
> > > > > On Thu, 11 Jul 2024 14:26:38 +1000
> > > > > David Gibson <david@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@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@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".    
> > > > 
> > > > 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?  
> > > 
> > > 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.
> 
> 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.
> 
> 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 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'.
> 

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-07-17  0:49 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-05  2:06 [PATCH v7 00/27] Unified flow table David Gibson
2024-07-05  2:06 ` [PATCH v7 01/27] flow: Common address information for initiating side David Gibson
2024-07-05  2:06 ` [PATCH v7 02/27] flow: Common address information for target side David Gibson
2024-07-10 21:30   ` Stefano Brivio
2024-07-11  0:19     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 03/27] tcp, flow: Remove redundant information, repack connection structures David Gibson
2024-07-05  2:07 ` [PATCH v7 04/27] tcp: Obtain guest address from flowside David Gibson
2024-07-05  2:07 ` [PATCH v7 05/27] tcp: Manage outbound address via flow table David Gibson
2024-07-05  2:07 ` [PATCH v7 06/27] tcp: Simplify endpoint validation using flowside information David Gibson
2024-07-05  2:07 ` [PATCH v7 07/27] tcp_splice: Eliminate SPLICE_V6 flag David Gibson
2024-07-05  2:07 ` [PATCH v7 08/27] tcp, flow: Replace TCP specific hash function with general flow hash David Gibson
2024-07-05  2:07 ` [PATCH v7 09/27] flow, tcp: Generalise TCP hash table to general flow hash table David Gibson
2024-07-05  2:07 ` [PATCH v7 10/27] tcp: Re-use flow hash for initial sequence number generation David Gibson
2024-07-05  2:07 ` [PATCH v7 11/27] icmp: Remove redundant id field from flow table entry David Gibson
2024-07-05  2:07 ` [PATCH v7 12/27] icmp: Obtain destination addresses from the flowsides David Gibson
2024-07-05  2:07 ` [PATCH v7 13/27] icmp: Look up ping flows using flow hash David Gibson
2024-07-05  2:07 ` [PATCH v7 14/27] icmp: Eliminate icmp_id_map David Gibson
2024-07-05  2:07 ` [PATCH v7 15/27] flow: Helper to create sockets based on flowside David Gibson
2024-07-10 21:32   ` Stefano Brivio
2024-07-11  0:21     ` David Gibson
2024-07-11  0:27     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 16/27] icmp: Manage outbound socket address via flow table David Gibson
2024-07-05  2:07 ` [PATCH v7 17/27] flow, tcp: Flow based NAT and port forwarding for TCP David Gibson
2024-07-05  2:07 ` [PATCH v7 18/27] flow, icmp: Use general flow forwarding rules for ICMP David Gibson
2024-07-05  2:07 ` [PATCH v7 19/27] fwd: Update flow forwarding logic for UDP David Gibson
2024-07-08 21:26   ` Stefano Brivio
2024-07-09  0:19     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 20/27] udp: Create flows for datagrams from originating sockets David Gibson
2024-07-09 22:32   ` Stefano Brivio
2024-07-09 23:59     ` David Gibson
2024-07-10 21:35       ` Stefano Brivio
2024-07-11  4:26         ` David Gibson
2024-07-11  8:20           ` Stefano Brivio
2024-07-11 22:58             ` David Gibson
2024-07-12  8:21               ` Stefano Brivio
2024-07-15  4:06                 ` David Gibson
2024-07-15 16:37                   ` Stefano Brivio
2024-07-17  0:49                     ` David Gibson [this message]
2024-07-05  2:07 ` [PATCH v7 21/27] udp: Handle "spliced" datagrams with per-flow sockets David Gibson
2024-07-09 22:32   ` Stefano Brivio
2024-07-10  0:23     ` David Gibson
2024-07-10 17:13       ` Stefano Brivio
2024-07-11  1:30         ` David Gibson
2024-07-11  8:23           ` Stefano Brivio
2024-07-11  2:48         ` David Gibson
2024-07-12 13:34   ` Stefano Brivio
2024-07-15  4:32     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 22/27] udp: Remove obsolete splice tracking David Gibson
2024-07-10 21:36   ` Stefano Brivio
2024-07-11  0:43     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 23/27] udp: Find or create flows for datagrams from tap interface David Gibson
2024-07-10 21:36   ` Stefano Brivio
2024-07-11  0:45     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 24/27] udp: Direct datagrams from host to guest via flow table David Gibson
2024-07-10 21:37   ` Stefano Brivio
2024-07-11  0:46     ` David Gibson
2024-07-05  2:07 ` [PATCH v7 25/27] udp: Remove obsolete socket tracking David Gibson
2024-07-05  2:07 ` [PATCH v7 26/27] udp: Remove rdelta port forwarding maps David Gibson
2024-07-05  2:07 ` [PATCH v7 27/27] udp: Rename UDP listening sockets David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZpcVKxfS3MjTLQ8p@zatzit \
    --to=david@gibson.dropbear.id.au \
    --cc=jmaloy@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).