From: David Gibson <david@gibson.dropbear.id.au>
To: passt-dev@passt.top, Stefano Brivio <sbrivio@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Subject: [PATCH v4 00/16] RFC: Unified flow table
Date: Fri, 3 May 2024 11:11:19 +1000 [thread overview]
Message-ID: <20240503011135.2924437-1-david@gibson.dropbear.id.au> (raw)
This is a fourth draft of the first steps in implementing more general
"connection" tracking, as described at:
https://pad.passt.top/p/NewForwardingModel
This series changes the TCP connection table and hash table into a
more general flow table that can track other protocols as well. Each
flow uniformly keeps track of all the relevant addresses and ports,
which will allow for more robust control of NAT and port forwarding.
ICMP is converted to use the new flow table.
This doesn't include UDP, but I'm working on it right now and making
progress. I'm posting this to give a head start on the review :)
Caveats:
* We significantly increase the size of a connection/flow entry
- Can probably be mitigated, but I haven't investigated much yet
* We perform a number of extra getsockname() calls to know some of
the socket endpoints
- Haven't yet measured how much performance impact that has
- Can be mitigated in at least some cases, but again, haven't
tried yet
Changes since v4:
* Complex rebase on top of the many things that have happened
upstream since v3.
* Assorted other changes.
Changes since v3:
* Replace TAPFSIDE() and SOCKFSIDE() macros with local variables.
Changes since v2:
* Cosmetic fixes based on review
* Extra doc comments for enum flow_type
* Rename flowside to flowaddrs which turns out to make more sense in
light of future changes
* Fix bug where the socket flowaddrs for tap initiated connections
wasn't initialised to match the socket address we were using in the
case of map-gw NAT
* New flowaddrs_from_sock() helper used in most cases which is cleaner
and should avoid bugs like the above
* Using newer centralised workarounds for clang-tidy issue 58992
* Remove duplicate definition of FLOW_MAX as maximum flow type and
maximum number of tracked flows
* Rebased on newer versions of preliminary work (ICMP, flow based
dispatch and allocation, bind/address cleanups)
* Unified hash table as well as base flow table
* Integrated ICMP
Changes since v1:
* Terminology changes
- "Endpoint" address/port instead of "correspondent" address/port
- "flowside" instead of "demiflow"
* Actually move the connection table to a new flow table structure in
new files
* Significant rearrangement of earlier patchs on top of that new
table, to reduce churn
David Gibson (16):
flow: Common data structures for tracking flow addresses
tcp: Maintain flowside information for "tap" connections
tcp_splice: Maintain flowside information for spliced connections
tcp: Obtain guest address from flowside
tcp: Simplify endpoint validation using flowside information
tcp, tcp_splice: Construct sockaddrs for connect() from flowside
tcp_splice: Eliminate SPLICE_V6 flag
tcp, flow: Replace TCP specific hash function with general flow hash
flow, tcp: Generalise TCP hash table to general flow hash table
tcp: Re-use flow hash for initial sequence number generation
icmp: Populate flowside information
icmp: Use flowsides as the source of truth wherever possible
icmp: Look up ping flows using flow hash
icmp: Eliminate icmp_id_map
flow, tcp: flow based NAT and port forwarding for TCP
flow, icmp: Use general flow forwarding rules for ICMP
flow.c | 199 ++++++++++++++++++++-
flow.h | 97 +++++++++++
fwd.c | 139 +++++++++++++++
fwd.h | 5 +
icmp.c | 83 +++++----
icmp_flow.h | 1 -
inany.h | 29 +++-
passt.h | 3 +
pif.h | 1 -
tap.c | 11 --
tap.h | 1 -
tcp.c | 475 +++++++++++++--------------------------------------
tcp_conn.h | 20 +--
tcp_splice.c | 93 ++--------
tcp_splice.h | 5 +-
15 files changed, 649 insertions(+), 513 deletions(-)
--
2.44.0
next reply other threads:[~2024-05-03 1:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-03 1:11 David Gibson [this message]
2024-05-03 1:11 ` [PATCH v4 01/16] flow: Common data structures for tracking flow addresses David Gibson
2024-05-13 18:07 ` Stefano Brivio
2024-05-14 0:11 ` David Gibson
2024-05-03 1:11 ` [PATCH v4 02/16] tcp: Maintain flowside information for "tap" connections David Gibson
2024-05-13 18:07 ` Stefano Brivio
2024-05-14 0:15 ` David Gibson
2024-05-03 1:11 ` [PATCH v4 03/16] tcp_splice: Maintain flowside information for spliced connections David Gibson
2024-05-03 1:11 ` [PATCH v4 04/16] tcp: Obtain guest address from flowside David Gibson
2024-05-13 18:07 ` Stefano Brivio
2024-05-14 0:18 ` David Gibson
2024-05-03 1:11 ` [PATCH v4 05/16] tcp: Simplify endpoint validation using flowside information David Gibson
2024-05-03 1:11 ` [PATCH v4 06/16] tcp, tcp_splice: Construct sockaddrs for connect() from flowside David Gibson
2024-05-03 1:11 ` [PATCH v4 07/16] tcp_splice: Eliminate SPLICE_V6 flag David Gibson
2024-05-03 1:11 ` [PATCH v4 08/16] tcp, flow: Replace TCP specific hash function with general flow hash David Gibson
2024-05-03 1:11 ` [PATCH v4 09/16] flow, tcp: Generalise TCP hash table to general flow hash table David Gibson
2024-05-03 1:11 ` [PATCH v4 10/16] tcp: Re-use flow hash for initial sequence number generation David Gibson
2024-05-03 1:11 ` [PATCH v4 11/16] icmp: Populate flowside information David Gibson
2024-05-03 1:11 ` [PATCH v4 12/16] icmp: Use flowsides as the source of truth wherever possible David Gibson
2024-05-03 1:11 ` [PATCH v4 13/16] icmp: Look up ping flows using flow hash David Gibson
2024-05-03 1:11 ` [PATCH v4 14/16] icmp: Eliminate icmp_id_map David Gibson
2024-05-03 1:11 ` [PATCH v4 15/16] flow, tcp: flow based NAT and port forwarding for TCP David Gibson
2024-05-03 1:11 ` [PATCH v4 16/16] flow, icmp: Use general flow forwarding rules for ICMP 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=20240503011135.2924437-1-david@gibson.dropbear.id.au \
--to=david@gibson.dropbear.id.au \
--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).