quinn icon indicating copy to clipboard operation
quinn copied to clipboard

Relax MAX_TRANSMIT_SEGMENTS

Open filipe-cantarelli opened this issue 8 months ago • 4 comments

After moving MAX_TRANSMIT_SEGMENTS limitation from quinn-proto to quinn in https://github.com/quinn-rs/quinn/pull/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

filipe-cantarelli avatar Mar 25 '25 16:03 filipe-cantarelli

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.

Ralith avatar Mar 25 '25 23:03 Ralith

@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?

filipe-cantarelli avatar Mar 31 '25 16:03 filipe-cantarelli

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

Ralith avatar Apr 03 '25 17:04 Ralith

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

Nit: with fast-apple-datapath (https://github.com/quinn-rs/quinn/pull/1993) it does advertise it, but then actually does a larse sendmsg_x. Not sure this is relevant here.

https://github.com/quinn-rs/quinn/blob/c94fa9bacbb71bfd737245539e678e9be9be7d66/quinn-udp/src/unix.rs#L845-L848

mxinden avatar Apr 03 '25 18:04 mxinden