Relax MAX_TRANSMIT_SEGMENTS

[filipe-cantarelli]

After moving MAX_TRANSMIT_SEGMENTS limitation from quinn-proto to quinn in #2185 , I'd like to understand if it's possible to relax it, by either increasing it or dropping.

This issue was created to follow up on this discussion and decide the path forward. Are there any benchmarks on the subject? I suspect at a minimum we want to:

• Test a range of values for it: 10,30,60...
• Test in the major supported platforms
• Possibly test it with different MTU sizes? 1200, 1500(ethernet), but also testing with Jumbo frames?

What's the data we want to collect? Possbily:

• Throughput
• Latency
• Error rate

[Ralith]

Another interesting variable is memory use. Each connection has a send buffer that may grow as required to fit a GSO batch. If e.g. a Windows server, capable of 512-datagram GSO batches, has a large number of concurrent connections, each of which at some point requests a large amount of data, then the worst-case memory use might add up more than users expect.

[filipe-cantarelli]

@Ralith I can only test Windows and Linux, will not be able to test Mac. If that's fine with you, can you assign this one to me?

[Ralith]

macOS doesn't actually support segmentation offload, so that works fine. Thanks!

[mxinden]

macOS doesn't actually support segmentation offload, so that works fine. Thanks!

Nit: with fast-apple-datapath (#1993) it does advertise it, but then actually does a larse sendmsg_x. Not sure this is relevant here.

quinn/quinn-udp/src/unix.rs

Lines 845 to 848 in c94fa9b

	#[cfg(apple_fast)]
	{
	BATCH_SIZE
	}