From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id E4DF15A026F for ; Thu, 18 Jan 2024 02:22:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1705540958; bh=9UGmockpg3Umn273c6QNHNmIRjz6d6qnAXGNiNMw67o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AbNwaJ+9+LeIZ+L8/y917FT2YcXzfYper9n03NMhCRlxRpiZWOJGayr3qB5OlnFGN 77FHERmnLcQsqZJ+L/+IHTlV+DhNl/dJQSs5s9ITFtpVsAZmt6sgZ2rXQBH9vTKJTx BezxULyDMxuTpls3qsBgQvcq3Iuot0qO0bNZp4wUQhjt4WmBdjbzx6X7EDJ7BmMph5 v47Sf6u52CVK/Yde35ZgyiUUsNvmvKUVUUVqWoorQELa/ZlUFJ1nmATFS6AVlx9l64 crx5CVwrUOt3h3fYDBibNNd7cPoZq1Zu8zbLRs27Y+XvVqeXJNyTbllXEAGReJZCrV gW9yVY3X9sntg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4TFlNZ36lrz4xNH; Thu, 18 Jan 2024 12:22:38 +1100 (AEDT) Date: Thu, 18 Jan 2024 12:22:29 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 12/15] icmp: Populate and use host side flow information Message-ID: References: <20231221070237.1422557-1-david@gibson.dropbear.id.au> <20231221070237.1422557-13-david@gibson.dropbear.id.au> <20240117205941.2dffe678@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wMj/3ArSfHF79gpP" Content-Disposition: inline In-Reply-To: <20240117205941.2dffe678@elisabeth> Message-ID-Hash: IUFUHUOF26FPM7BPADXKS5PBMAU6FZLH X-Message-ID-Hash: IUFUHUOF26FPM7BPADXKS5PBMAU6FZLH X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --wMj/3ArSfHF79gpP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 17, 2024 at 08:59:41PM +0100, Stefano Brivio wrote: > On Thu, 21 Dec 2023 18:02:34 +1100 > David Gibson wrote: >=20 > > Complete filling out the common flow information for "ping" flows by > > storing the host side information for the ping socket. We can only > > retrieve this from the socket after we send the echo-request, because > > that's when the kernel will assign an ID. > >=20 > > Signed-off-by: David Gibson > > --- > > icmp.c | 36 +++++++++++++++++++++++++++++++++--- > > 1 file changed, 33 insertions(+), 3 deletions(-) > >=20 > > diff --git a/icmp.c b/icmp.c > > index 53ad087..917c810 100644 > > --- a/icmp.c > > +++ b/icmp.c > > @@ -310,11 +310,41 @@ int icmp_tap_handler(const struct ctx *c, uint8_t= pif, int af, > > if (sendto(pingf->sock, pkt, plen, MSG_NOSIGNAL, &sa.sa, sl) < 0) { > > debug("%s: failed to relay request to socket: %s", > > pname, strerror(errno)); > > - } else { > > - debug("%s: echo request to socket, ID: %"PRIu16", seq: %"PRIu16, > > - pname, id, seq); > > + if (flow) > > + goto cancel; > > + } > > + > > + debug("%s: echo request to socket, ID: %"PRIu16", seq: %"PRIu16, > > + pname, id, seq); > > + > > + if (!flow) > > + /* Nothing more to do for an existing flow */ > > + return 1; > > + > > + /* We need to wait until after the sendto() to fill in the SOCKSIDE > > + * information, so that we can find out the host side id the kernel > > + * assigned. If there's no bind address specified, this will still h= ave > > + * 0.0.0.0 or :: as the host side forwarding address. There's not > > + * really anything we can do to fill that in, which means we can never > > + * insert the SOCKSIDE of a ping flow into the hash table. > > + */ >=20 > Well, if it was just because of that we could argue at some point that, > with wildcards or suchlike, we could insert that in the hash table as > well. If we allow wildcards, it's probably not a hash table any more, or at least not a normal one. Hashing is pretty inherently tied to a single value lookup. > But that wouldn't make sense anyway, right? That is, unless I'm missing > something, we would have no use for a hash table lookup of the SOCKSIDE > of a ping flow anyway. That's correct, which is why we can get away with this. Likewise SOCKSIDE of tcp flows is also never hashed. However in some cases we may want to hash the host sides of flows: I think we'll want to for UDP, for example, because we can receive multiple flows via the same bound socket. That's why I want to be very clear about when and why we're constructing a flowside that can't be hashed. --=20 David Gibson | 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 --wMj/3ArSfHF79gpP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmWofVQACgkQzQJF27ox 2GduLg/8D+l89f0Dqvaq76H+gsdh97EMZewOrkc/OIVkxZBrN6cCPaHI8pfLdhpZ 2Ep+adViNZchLiZx526xD7r9xRqFdWwoeNmjPc1Ltq7kz+5L1ahZifqjyzG/qtYn r3f/elTf7QYfUbMvJMxbfmlx/VH5VGkX/2XLQmz5FJvaal/l8D5TS7MLExYbiZai V1VLpqU+zb9xndfLzkzdF2q4LbeFflZQnAVeHt61HmEThY/8y/b77gIY1paTI4Jf H/a4C8j7xdQNgBegdsRa3+zTpUUh926Rk8kWHyP4LCdxkO2jxJ9Lc1+mWsXHkfJe 68D83v0DIvywDAnpvvGbOvpitmDh/rnnbYXUilqosNLoKbY7/oBUp15qV06ybZs8 KpaanhVA1NHKKyw6aLfnnYCzpghc0iuu3tX5mtmahRgDE6DL0/FgTuW6qjuA3OpW 2mjI0NkxBIKaCHgPuQnt0oCXqt+SV8la/LRG0hLXr1Y5z1l9QT6kc/sayp2s+U9n u5pnDQW0VzIx7C8ClrYBZvwXrL4k3jDFJiqGD2aDtVcq5Cy9KHOUAKR35mQZ8Gxg NkzNwjHI4wE5yCN+qLtE9OYbzDyY3UgUAu1DlW366ki2Ty8qUXdko0gIT1pge5HT No3GtMienmm17fDogEYwKQ6qmIKkJTY5WUZJg+FC5gwLcCK3TcA= =CYuX -----END PGP SIGNATURE----- --wMj/3ArSfHF79gpP--