From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v3 06/15] tcp, flow: Replace TCP specific hash function with general flow hash
Date: Wed, 17 Jan 2024 20:59:34 +0100 [thread overview]
Message-ID: <20240117205934.4b7d7043@elisabeth> (raw)
In-Reply-To: <20231221070237.1422557-7-david@gibson.dropbear.id.au>
On Thu, 21 Dec 2023 18:02:28 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> Currently we match TCP packets received on the tap connection to a TCP
> connection via a hash table based on the forwarding address and both
> ports. We hope in future to allow for multiple guest side addresses, or
> for multiple interfaces which means we may need to distinguish based on
> the endpoint address and pif as well. We also want a unified hash table
> to cover multiple protocols, not just TCP.
>
> Replace the TCP specific hash function with one suitable for general flows,
> or rather for one side of a general flow. This includes all the
> information from struct flowside, plus the L4 protocol number.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> flow.c | 21 +++++++++++++++++++++
> flow.h | 19 +++++++++++++++++++
> tcp.c | 59 +++++++++++-----------------------------------------------
> 3 files changed, 51 insertions(+), 48 deletions(-)
>
> diff --git a/flow.c b/flow.c
> index bc8cfc6..263633e 100644
> --- a/flow.c
> +++ b/flow.c
> @@ -229,6 +229,27 @@ void flow_alloc_cancel(union flow *flow)
> flow_first_free = FLOW_IDX(flow);
> }
>
> +/**
> + * flow_hash() - Calculate hash value for one side of a flow
> + * @c: Execution context
> + * @proto: Protocol of this flow (IP L4 protocol number)
> + * @fside: Flowside
> + *
> + * Return: hash value
> + */
> +uint64_t flow_hash(const struct ctx *c, uint8_t proto,
> + const struct flowside *fside)
> +{
> + struct siphash_state state = SIPHASH_INIT(c->hash_secret);
> +
> + ASSERT(flowside_complete(fside));
> + inany_siphash_feed(&state, &fside->faddr);
> + inany_siphash_feed(&state, &fside->eaddr);
Customary newline here.
> + return siphash_final(&state, 38, (uint64_t)proto << 40 |
> + (uint64_t)fside->pif << 32 |
> + fside->fport << 16 | fside->eport);
If we add the fields from the 'tail' part (not the whole fside) to an
anonymous struct in a similar way to what we had before fc8f0f8c48ef
("siphash: Use incremental rather than all-at-once siphash functions"),
then we could drop those shift and masks, and use sizeof(that) +
sizeof(fside->faddr) + sizeof(fside->eaddr) instead of '38'.
> +}
> +
> /**
> * flow_defer_handler() - Handler for per-flow deferred and timed tasks
> * @c: Execution context
> diff --git a/flow.h b/flow.h
> index e7c4484..72ded54 100644
> --- a/flow.h
> +++ b/flow.h
> @@ -81,6 +81,22 @@ static inline bool flowside_complete(const struct flowside *fside)
>
> #define SIDES 2
>
> +/**
> + * flowside_eq() - Check if two flowsides are equal
...this raises the question: if the protocol number is now used in the
hash, shouldn't it eventually become part of struct flowside -- and
compared here, too?
I guess it's useful iff we allow flowsides for the same flow to have
different protocol numbers.
Now, forwarding between TCP and UDP endpoints might not make a lot of
sense, because we would have to make so many arbitrary assumptions as
to make it probably not generic enough to be useful.
But TCP to stream-oriented UNIX domain socket makes sense, and we also
had user requests in that sense. Oh and... what would be the second
protocol number in that case?
Same here, I'm not proposing a concrete change here, I'm rather raising
this if you didn't think about it (assuming it makes any sense).
> + * @left, @right: Flowsides to compare
> + *
> + * Return: true if equal, false otherwise
> + */
> +static inline bool flowside_eq(const struct flowside *left,
> + const struct flowside *right)
> +{
> + return left->pif == right->pif &&
> + inany_equals(&left->eaddr, &right->eaddr) &&
> + left->eport == right->eport &&
> + inany_equals(&left->faddr, &right->faddr) &&
> + left->fport == right->fport;
Preferably align under "return ".
--
Stefano
next prev parent reply other threads:[~2024-01-17 19:59 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-21 7:02 [PATCH v3 00/15] RFC: Unified flow table David Gibson
2023-12-21 7:02 ` [PATCH v3 01/15] flow: Common data structures for tracking flow addresses David Gibson
2024-01-13 22:50 ` Stefano Brivio
2024-01-16 6:14 ` David Gibson
2023-12-21 7:02 ` [PATCH v3 02/15] tcp, flow: Maintain guest side flow information David Gibson
2024-01-13 22:51 ` Stefano Brivio
2024-01-16 6:23 ` David Gibson
2023-12-21 7:02 ` [PATCH v3 03/15] tcp, flow: Maintain host " David Gibson
2023-12-21 7:02 ` [PATCH v3 04/15] tcp_splice,flow: Maintain flow information for spliced connections David Gibson
2024-01-17 19:59 ` Stefano Brivio
2024-01-18 1:01 ` David Gibson
2023-12-21 7:02 ` [PATCH v3 05/15] flow, tcp, tcp_splice: Uniform debug helpers for new flows David Gibson
2024-01-17 19:59 ` Stefano Brivio
2024-01-18 1:04 ` David Gibson
2024-01-18 15:40 ` Stefano Brivio
2023-12-21 7:02 ` [PATCH v3 06/15] tcp, flow: Replace TCP specific hash function with general flow hash David Gibson
2024-01-17 19:59 ` Stefano Brivio [this message]
2024-01-18 1:15 ` David Gibson
2024-01-18 15:42 ` Stefano Brivio
2024-01-18 23:55 ` David Gibson
2023-12-21 7:02 ` [PATCH v3 07/15] flow: Add helper to determine a flow's protocol David Gibson
2023-12-21 7:02 ` [PATCH v3 08/15] flow, tcp: Generalise TCP hash table to general flow hash table David Gibson
2023-12-21 7:02 ` [PATCH v3 09/15] tcp: Re-use flow hash for initial sequence number generation David Gibson
2023-12-21 7:02 ` [PATCH v3 10/15] icmp: Store ping socket information in the flow table David Gibson
2023-12-21 7:02 ` [PATCH v3 11/15] icmp: Populate guest side information for ping flows David Gibson
2023-12-21 7:02 ` [PATCH v3 12/15] icmp: Populate and use host side flow information David Gibson
2024-01-17 19:59 ` Stefano Brivio
2024-01-18 1:22 ` David Gibson
2024-01-18 15:43 ` Stefano Brivio
2024-01-18 23:58 ` David Gibson
2023-12-21 7:02 ` [PATCH v3 13/15] icmp: Use 'flowside' epoll references for ping sockets David Gibson
2023-12-21 7:02 ` [PATCH v3 14/15] icmp: Merge EPOLL_TYPE_ICMP and EPOLL_TYPE_ICMPV6 David Gibson
2023-12-21 7:02 ` [PATCH v3 15/15] icmp: Eliminate icmp_id_map 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=20240117205934.4b7d7043@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/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).