RFC: Tie `MAX_GSO_SEGMENTS` on Windows to socket state

[thomaseizinger]

Currently, MAX_GSO_SEGMENTS on Windows is wrapped in a LazyLock and therefore only evaluates once for the entire lifetime of the program in memory.

In our experience, the support for things like URO/GRO/GSO is tied to the current network driver and thus can change at runtime when the user e.g. plugs their laptop into a dock.

Hence, I believe it would be good to tie this state to the UdpSocketState instead to allow applications to re-evaluate this on their own terms. In Firezone for example, we detect when the user roams networks and reset all kinds of network state in order to make things work again.

Thoughts?

[djc]

Seems sensible to me.

[mxinden]

Would we determine MAX_GSO_SEGMENTS on each new socket? If so, isn't that quite expensive?

quinn/quinn-udp/src/windows.rs

Lines 497 to 515 in 0dcf9d9

	static MAX_GSO_SEGMENTS: LazyLock<usize> = LazyLock::new(|| {
	let socket = match std::net::UdpSocket::bind("[::]:0")
	.or_else(|_| std::net::UdpSocket::bind((Ipv4Addr::LOCALHOST, 0)))
	{
	Ok(socket) => socket,
	Err(_) => return 1,
	};
	const GSO_SIZE: c_uint = 1500;
	match set_socket_option(
	&socket,
	WinSock::IPPROTO_UDP,
	WinSock::UDP_SEND_MSG_SIZE,
	GSO_SIZE,
	) {
	// Empirically found on Windows 11 x64
	Ok(()) => 512,
	Err(_) => 1,
	}
	});

[thomaseizinger]

Would we determine MAX_GSO_SEGMENTS on each new socket? If so, isn't that quite expensive?

I think if we do it per socket, there is no need to open an additional socket to check that it works? So it should only be a single syscall which isn't that bad I guess? At least in Firezone, we don't use quinn-udp for all our UDP needs, only those that need good UDP IO. DNS queries for example are sent from "regular" sockets.