- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 16 Jul 2021 06:34:32 +0000
- To: Willy Tarreau <w@1wt.eu>
- cc: Toerless Eckert <tte@cs.fau.de>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
-------- Willy Tarreau writes: > Stefan made a good point about the problem that might result, with > inbound load balancing between multiple listeners (typically what's > achieved by L3 switches doing L3+L4 hash between multiple servers, > and operating systems hashing the source+destination port to pick a > different listening socket). Thus a suggestion might be to possibly > save resources by using a small amount of sockets, with "small" left > to the appreciation of the implementation. We should run the question "few or many UDP ports?" past some some friendly 100G and 400G device driver maintainers. The NICs I have been working with for the ESO ELT project all included UDP ports in the hash they used to decide which CPU core to deliver packets/interrupts to and we had to spread across UDP ports to or all the traffic would hit one single core. I dont know if QUIC has registered with the NIC designers and device drivers writers yet, but given the opacity of QUIC packets, it is very hard to see what else than the UDP port they can feed into their hash, so I expect the answer to be "many". But it would best to ask, and find out how important they think it will be, and what "many" means for them. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Friday, 16 July 2021 06:34:49 UTC