Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax MAX_TRANSMIT_SEGMENTS #2189

Open
filipe-cantarelli opened this issue Mar 25, 2025 · 2 comments
Open

Relax MAX_TRANSMIT_SEGMENTS #2189

filipe-cantarelli opened this issue Mar 25, 2025 · 2 comments

Comments

@filipe-cantarelli
Copy link
Contributor

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
Copy link
Collaborator

Ralith commented Mar 25, 2025

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants