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, 10 Jul 2024 09:59:08 +1000	[thread overview]
Message-ID: <Zo3OzDz0ChwZBO4C@zatzit> (raw)
In-Reply-To: <20240710003202.2909199a@elisabeth>

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

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:
> 
> > This implements the first steps of tracking UDP packets with the flow table
> > rather than it's own (buggy) set of port maps.  Specifically we create flow
> 
> its

Oops, fixed.

> > table entries for datagrams received from a socket (PIF_HOST or
> > PIF_SPLICE).
> > 
> > When splitting datagrams from sockets into batches, we group by the flow
> > as well as splicesrc.  This may result in smaller batches, but makes things
> > easier down the line.  We can re-optimise this later if necessary.  For now
> > we don't do anything else with the flow, not even match reply packets to
> > the same flow.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  Makefile     |   2 +-
> >  flow.c       |  31 ++++++++++
> >  flow.h       |   4 ++
> >  flow_table.h |  14 +++++
> >  udp.c        | 169 +++++++++++++++++++++++++++++++++++++++++++++++++--
> >  udp_flow.h   |  25 ++++++++
> >  6 files changed, 240 insertions(+), 5 deletions(-)
> >  create mode 100644 udp_flow.h
> > 
> > diff --git a/Makefile b/Makefile
> > index 09fc461d..92cbd5a6 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -57,7 +57,7 @@ PASST_HEADERS = arch.h arp.h checksum.h conf.h dhcp.h dhcpv6.h flow.h fwd.h \
> >  	flow_table.h icmp.h icmp_flow.h inany.h iov.h ip.h isolation.h \
> >  	lineread.h log.h ndp.h netlink.h packet.h passt.h pasta.h pcap.h pif.h \
> >  	siphash.h tap.h tcp.h tcp_buf.h tcp_conn.h tcp_internal.h tcp_splice.h \
> > -	udp.h util.h
> > +	udp.h udp_flow.h util.h
> >  HEADERS = $(PASST_HEADERS) seccomp.h
> >  
> >  C := \#include <linux/tcp.h>\nstruct tcp_info x = { .tcpi_snd_wnd = 0 };
> > diff --git a/flow.c b/flow.c
> > index 218033ae..0cb9495b 100644
> > --- a/flow.c
> > +++ b/flow.c
> > @@ -37,6 +37,7 @@ const char *flow_type_str[] = {
> >  	[FLOW_TCP_SPLICE]	= "TCP connection (spliced)",
> >  	[FLOW_PING4]		= "ICMP ping sequence",
> >  	[FLOW_PING6]		= "ICMPv6 ping sequence",
> > +	[FLOW_UDP]		= "UDP flow",
> >  };
> >  static_assert(ARRAY_SIZE(flow_type_str) == FLOW_NUM_TYPES,
> >  	      "flow_type_str[] doesn't match enum flow_type");
> > @@ -46,6 +47,7 @@ const uint8_t flow_proto[] = {
> >  	[FLOW_TCP_SPLICE]	= IPPROTO_TCP,
> >  	[FLOW_PING4]		= IPPROTO_ICMP,
> >  	[FLOW_PING6]		= IPPROTO_ICMPV6,
> > +	[FLOW_UDP]		= IPPROTO_UDP,
> >  };
> >  static_assert(ARRAY_SIZE(flow_proto) == FLOW_NUM_TYPES,
> >  	      "flow_proto[] doesn't match enum flow_type");
> > @@ -700,6 +702,31 @@ flow_sidx_t flow_lookup_af(const struct ctx *c,
> >  	return flowside_lookup(c, proto, pif, &fside);
> >  }
> >  
> > +/**
> > + * flow_lookup_sa() - Look up a flow given and endpoint socket address
> 
> s/and/an/

Fixed.

> > + * @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.  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?

> > +		.fport = fport,
> > +	};
> > +
> > +	inany_from_sockaddr(&fside.eaddr, &fside.eport, esa);
> > +	if (inany_v4(&fside.eaddr))
> > +		fside.faddr = inany_any4;
> > +	else
> > +		fside.faddr = inany_any6;
> 
> The usual extra newline here?

Done.

> > +	return flowside_lookup(c, proto, pif, &fside);
> > +}
> > +
> >  /**
> >   * flow_defer_handler() - Handler for per-flow deferred and timed tasks
> >   * @c:		Execution context
> > @@ -779,6 +806,10 @@ void flow_defer_handler(const struct ctx *c, const struct timespec *now)
> >  			if (timer)
> >  				closed = icmp_ping_timer(c, &flow->ping, now);
> >  			break;
> > +		case FLOW_UDP:
> > +			if (timer)
> > +				closed = udp_flow_timer(c, &flow->udp, now);
> > +			break;
> >  		default:
> >  			/* Assume other flow types don't need any handling */
> >  			;
> > diff --git a/flow.h b/flow.h
> > index e27f99be..3752e5ee 100644
> > --- a/flow.h
> > +++ b/flow.h
> > @@ -115,6 +115,8 @@ enum flow_type {
> >  	FLOW_PING4,
> >  	/* ICMPv6 echo requests from guest to host and matching replies back */
> >  	FLOW_PING6,
> > +	/* UDP pseudo-connection */
> > +	FLOW_UDP,
> >  
> >  	FLOW_NUM_TYPES,
> >  };
> > @@ -238,6 +240,8 @@ flow_sidx_t flow_lookup_af(const struct ctx *c,
> >  			   uint8_t proto, uint8_t pif, sa_family_t af,
> >  			   const void *eaddr, const void *faddr,
> >  			   in_port_t eport, in_port_t fport);
> > +flow_sidx_t flow_lookup_sa(const struct ctx *c, uint8_t proto, uint8_t pif,
> > +			   const void *esa, in_port_t fport);
> >  
> >  union flow;
> >  
> > diff --git a/flow_table.h b/flow_table.h
> > index 457f27b1..3fbc7c8d 100644
> > --- a/flow_table.h
> > +++ b/flow_table.h
> > @@ -9,6 +9,7 @@
> >  
> >  #include "tcp_conn.h"
> >  #include "icmp_flow.h"
> > +#include "udp_flow.h"
> >  
> >  /**
> >   * struct flow_free_cluster - Information about a cluster of free entries
> > @@ -35,6 +36,7 @@ union flow {
> >  	struct tcp_tap_conn tcp;
> >  	struct tcp_splice_conn tcp_splice;
> >  	struct icmp_ping_flow ping;
> > +	struct udp_flow udp;
> >  };
> >  
> >  /* Global Flow Table */
> > @@ -78,6 +80,18 @@ static inline union flow *flow_at_sidx(flow_sidx_t sidx)
> >  	return FLOW(sidx.flow);
> >  }
> >  
> > +/** flow_sidx_opposite - Get the other side of the same flow
> 
> flow_sidx_opposite()

Done.

> > + * @sidx:	Flow & side index
> > + *
> > + * Return: sidx for the other side of the same flow as @sidx
> > + */
> > +static inline flow_sidx_t flow_sidx_opposite(flow_sidx_t sidx)
> > +{
> > +	if (!flow_sidx_valid(sidx))
> > +		return FLOW_SIDX_NONE;
> 
> Same here with the extra newline.

Done.

> > +	return (flow_sidx_t){.flow = sidx.flow, .side = !sidx.side};
> > +}
> > +
> >  /** flow_sidx_t - Index of one side of a flow from common structure
> >   * @f:		Common flow fields pointer
> >   * @side:	Which side to refer to (0 or 1)
> > diff --git a/udp.c b/udp.c
> > index 6427b9ce..daf4fe26 100644
> > --- a/udp.c
> > +++ b/udp.c
> > @@ -15,6 +15,30 @@
> >  /**
> >   * DOC: Theory of Operation
> >   *
> > + * UDP Flows
> > + * =========
> > + *
> > + * UDP doesn't have true connections, but many protocols use a connection-like
> > + * format.  The flow is initiated by a client sending a datagram from a port of
> > + * its choosing (usually ephemeral) to a specific port (usually well known) on a
> > + * server.  Both client and server address must be unicast.  The server sends
> > + * replies using the same addresses & ports with src/dest swapped.
> > + *
> > + * We track pseudo-connections of this type as flow table entries of type
> > + * FLOW_UDP.  We store the time of the last traffic on the flow in uflow->ts,
> > + * and let the flow expire if there is no traffic for UDP_CONN_TIMEOUT seconds.
> > + *
> > + * NOTE: This won't handle multicast protocols, or some protocols with different
> > + * port usage.  We'll need specific logic if we want to handle those.
> > + *
> > + * "Listening" sockets
> > + * ===================
> > + *
> > + * UDP doesn't use listen(), but we consider long term sockets which are allowed
> > + * to create new flows "listening" by analogy with TCP.
> > + *
> > + * Port tracking
> > + * =============
> >   *
> >   * For UDP, a reduced version of port-based connection tracking is implemented
> >   * with two purposes:
> > @@ -121,6 +145,7 @@
> >  #include "tap.h"
> >  #include "pcap.h"
> >  #include "log.h"
> > +#include "flow_table.h"
> >  
> >  #define UDP_CONN_TIMEOUT	180 /* s, timeout for ephemeral or local bind */
> >  #define UDP_MAX_FRAMES		32  /* max # of frames to receive at once */
> > @@ -199,6 +224,7 @@ static struct ethhdr udp6_eth_hdr;
> >   * @taph:	Tap backend specific header
> >   * @s_in:	Source socket address, filled in by recvmmsg()
> >   * @splicesrc:	Source port for splicing, or -1 if not spliceable
> > + * @tosidx:	sidx for the destination side of this datagram's flow
> >   */
> >  static struct udp_meta_t {
> >  	struct ipv6hdr ip6h;
> > @@ -207,6 +233,7 @@ static struct udp_meta_t {
> >  
> >  	union sockaddr_inany s_in;
> >  	int splicesrc;
> > +	flow_sidx_t tosidx;
> >  }
> >  #ifdef __AVX2__
> >  __attribute__ ((aligned(32)))
> > @@ -490,6 +517,115 @@ static int udp_mmh_splice_port(union epoll_ref ref, const struct mmsghdr *mmh)
> >  	return -1;
> >  }
> >  
> > +/**
> > + * udp_at_sidx() - Get UDP specific flow at given sidx
> > + * @sidx:    Flow and side to retrieve
> > + *
> > + * Return: UDP specific flow at @sidx, or NULL of @sidx is invalid.  Asserts if
> > + *         the flow at @sidx is not FLOW_UDP.
> > + */
> > +struct udp_flow *udp_at_sidx(flow_sidx_t sidx)
> > +{
> > +	union flow *flow = flow_at_sidx(sidx);
> > +
> > +	if (!flow)
> > +		return NULL;
> > +
> > +	ASSERT(flow->f.type == FLOW_UDP);
> > +	return &flow->udp;
> > +}
> > +
> > +/*
> > + * udp_flow_close() - Close and clean up UDP flow
> > + * @c:		Execution context
> > + * @uflow:	UDP flow
> > + */
> > +static void udp_flow_close(const struct ctx *c, const struct udp_flow *uflow)
> > +{
> > +	flow_hash_remove(c, FLOW_SIDX(uflow, INISIDE));
> > +}
> > +
> > +/**
> > + * udp_flow_new() - Common setup for a new UDP flow
> > + * @c:		Execution context
> > + * @flow:	Initiated flow
> > + * @now:	Timestamp
> > + *
> > + * Return: UDP specific flow, if successful, NULL on failure
> > + */
> > +static flow_sidx_t udp_flow_new(const struct ctx *c, union flow *flow,
> > +				const struct timespec *now)
> > +{
> > +	const struct flowside *ini = &flow->f.side[INISIDE];
> > +	struct udp_flow *uflow = NULL;
> > +
> > +	if (!inany_is_unicast(&ini->eaddr) || ini->eport == 0) {
> > +		flow_dbg(flow, "Invalid endpoint to initiate UDP flow");
> 
> Do we risk making debug logs unusable if we see multicast traffic?

Um.. I'm not sure.

> Maybe this could be flow_trace() instead.

Sure, why not.

-- 
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-10  0:23 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 [this message]
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
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=Zo3OzDz0ChwZBO4C@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).