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

backport to 0.9: Allow GSO to be manually disabled #1671

Merged
merged 1 commit into from
Sep 22, 2023

Conversation

grooviegermanikus
Copy link

@grooviegermanikus grooviegermanikus commented Sep 21, 2023

Hi,
we love quinn but we recently had a hard time with GSO and fly.io hosting and quinn 0.9.4!

This errors are piling up in the logs:

sendmsg error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }, Transmit: { destination: [dead:0:beef:a7b:17b:0101:2345:2]:11111, src_ip: None, enc: Some(Ect0), len: 1291, segment_size: Some(1200) }

After some research we concluded that quinn's GSO detection returns a false-positive - at least on fly.io machines!
Our reasoning:

  1. The problem went away by disabling GSO with patch a06838.
  2. fly.io support confirmed GSO is not supported on their platform!

Proposed Solution

short term: backport a06838 to allow manual disabling GSO
long term: backport a fix for the feature detection

maybe the solution should be ported to 0.10 too

@djc
Copy link
Member

djc commented Sep 21, 2023

Why are you not on 0.10 yet?

@Ralith
Copy link
Collaborator

Ralith commented Sep 22, 2023

As an alternative workaround, did you try ethtool -K $INTERFACE tx-udp-segmentation off?

@grooviegermanikus
Copy link
Author

As an alternative workaround, did you try ethtool -K $INTERFACE tx-udp-segmentation off?

Hi, let me check with ops!

yet I guess on PaaS-environments like fly.io that's tedious workaround. the deployment model on fly.io is to provide a docker image. access to OS level is possible but limited AFAIK.

@djc
Copy link
Member

djc commented Sep 22, 2023

maybe the solution should be ported to 0.10 too

This was done already, in #1638 (published in 0.10.3).

@grooviegermanikus
Copy link
Author

Why are you not on 0.10 yet?

we depend on a component we don't control

@djc
Copy link
Member

djc commented Sep 22, 2023

we depend on a component we don't control

Is that something public? Would like to have more information.

@grooviegermanikus
Copy link
Author

we depend on a component we don't control

Is that something public? Would like to have more information.

solana 1.16.x:
here https://github.com/solana-labs/solana/blob/c932953e7bd8f7db10a1c74c6ad29dd809307c70/Cargo.toml#L258
(master is on 0.10)

@djc
Copy link
Member

djc commented Sep 22, 2023

Ahh, okay, so released versions of Solana require 0.9 (master is on 0.10) and you depend on Solana. Thanks for the clarification!

@djc djc merged commit 71d3b4c into quinn-rs:0.9.x Sep 22, 2023
7 of 8 checks passed
@djc
Copy link
Member

djc commented Sep 22, 2023

If you submit a PR to bump the version on the 0.9.x branch I can publish a release right after that.

@Ralith
Copy link
Collaborator

Ralith commented Sep 22, 2023

yet I guess on PaaS-environments like fly.io that's tedious workaround. the deployment model on fly.io is to provide a docker image. access to OS level is possible but limited AFAIK.

I'm not much good at docker, but I think you can arrange for it to run a script on startup, which could include an ethtool invocation before invoking your actual service. This might be especially helpful if the quinn use is hidden in a dependency.

@grooviegermanikus
Copy link
Author

@djc here's the PR for version bump
Thanks a lot !

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

Successfully merging this pull request may close these issues.

3 participants