GSO support on Windows

[marten-seemann]

Apparently it's possible to use GSO on Windows. For reference (and code points), quinn just added support.

I don't particularly care about Windows too much, so I probably won't be working on this issue any time soon. If you're interested, please feel free to reach out or the send a PR.

[Samsonnyyeet]

Hey @marten-seemann

I'm interested in helping add GSO support for Windows. From my shallow inspection of the source code, and the linked quinn pr, I noticed that quinn sets the UDP_SEND_MSG_SIZE option. This flag is largely responsible for handling GSO support.

Reference:
Windows USO documentation

Implementing GSO support for Windows would require handling proper instantiation of this flag, and the creation of sys_conn_helper_windows.go file based on the structure of the linux implementation.

(I'd appreciate feedback/advice on my approach!)

[marten-seemann]

Your approach sounds reasonable. Are you developing on Windows? Will you be able to test your code, to make sure that it actually sends out multiple QUIC packets per syscall?

[Samsonnyyeet]

Hey! Really sorry for the delay. As it happens, my network card doesn't actually support GSO. I'm currently in the process of temporarily acquiring a laptop which supports GSO for the development of this feature.

Are you developing on Windows?

Yep! I found your PRs which implemented GSO for linux and those were quite helpful to understand the general process of going about things.

[marten-seemann]

Thanks for the update! Looking forward to your PR!

[mxinden]

For what it is worth, here is Quinn's USO and URO implementation, where USO and URO are the Windows equivalent of Linux's GSO and GRO.

https://github.com/quinn-rs/quinn/blob/main/quinn-udp/src/windows.rs

Also note that we are currently facing issues with URO on Windows on ARM, which might or might not be related to the Quinn implementation itself.

quinn-rs/quinn#2041

[Samsonnyyeet]

Hey! FINALLY got my hands on a laptop with offloading support 😎.

I had a quick question. Please correct me if I'm wrong, but the windows specific implementation is using only basicConn. The linux implementation is relying on the oobConn struct built on top of OOBCapablePacketConn to implement GSO, and other functionalities. How should I structure the GSO support for windows? I assume making changes to the basicConn (to add a GSO support boolean) is not a good idea. Should I make another struct just for this on top of OOBCapablePacketConn similar to oobConn but specifically for windows?

[marten-seemann]

Hey! FINALLY got my hands on a laptop with offloading support 😎.

That's great!

Please correct me if I'm wrong, but the windows specific implementation is using only basicConn. The linux implementation is relying on the oobConn struct built on top of OOBCapablePacketConn to implement GSO, and other functionalities. How should I structure the GSO support for windows? I assume making changes to the basicConn (to add a GSO support boolean) is not a good idea.

You're right. basicConn is supposed to be a dumb conn that doesn't enable any optimizations, but which at least allows us to send out UDP datagrams on systems that don't support anything else.

OOBCapablePacketConn is referring to the OOB field in the ivp4.Message. Am I right to assume that on Windows we need to pass some OOB data as well? If that's the case, is there any reason to not use the OOBCapablePacketConn there?

[Samsonnyyeet]

Ah, I see what you mean. I figured there was a reason OOBCapablePacketConn wasn't used for windows. Since that's not an issue I'll go ahead with integrating windows specific code to use OOBCapablePacketConn.