feat(s2n-quic-qns): add xdp client #1838
Conversation
camshaft
force-pushed
the
camshaft/xdp-qns-client
branch
2 times, most recently
from
6d40fa5 to
6ec13ed
Compare
camshaft
force-pushed
the
camshaft/xdp-qns-client
branch
2 times, most recently
from
d693f10 to
56322f9
Compare
quic/s2n-quic-platform/src/io/xdp.rs
Outdated
| // Initial packets don't need to be bigger than the minimum | ||
| let max_mtu = s2n_quic_core::path::MaxMtu::MIN; | ||
|
|
||
| // It's unlikely the initial packets will utilize, so just disable it |
There was a problem hiding this comment.
| // It's unlikely the initial packets will utilize, so just disable it | |
| // It's unlikely the initial packets will utilize GSO, so just disable it |
quic/s2n-quic-platform/src/io/xdp.rs
Outdated
| // compute the payload size for each message from the number of GSO segments we can | ||
| // fill |
There was a problem hiding this comment.
this comment is a little confusing after the previous one about not utilizing gso
There was a problem hiding this comment.
Yeah that was copy/pasted from the tokio code 😄
quic/s2n-quic-qns/src/xdp.rs
Outdated
|
|
||
| if let Ok(udp_socket) = recv_udp_socket { | ||
| let udp_socket = tokio::net::UdpSocket::from_std(udp_socket)?; | ||
| // Set up a task to read from the bound UDP socket |
There was a problem hiding this comment.
So this exists just to verify everything is working properly? Would it make sense to do something more severe than logging if a packet is received?
There was a problem hiding this comment.
Yeah that's correct. I can shut down the process with an error message if you think that's better.
Another option is to merge the queues and still process them in the endpoint. But the problem with that is it'll be using normal UDP sockets and you won't really have any insight that that's happening...
There was a problem hiding this comment.
I don't really have a sense of why this would happen or how likely it is. If you think it would only happen as soon as the process starts up then maybe its better to shut down with an error, otherwise I could see this spamming logs pretty heavily.
There was a problem hiding this comment.
Yeah if this starts logging the cause would likely be that the XDP program was unloaded, which we wouldn't recover from in the current code since we'd have to re-register all of the map values. So in this example code I think it's best to shut it down.
camshaft
force-pushed
the
camshaft/xdp-qns-client
branch
from
56322f9 to
33ecdee
Compare
2 participants
Description of changes:
Similar to #1765, this change adds a client.
The interesting thing about the client is, since it's the one to initiate the connection, it doesn't know any of the ethernet addresses, or even its own source IP in some cases. So what we do is open a UDP socket to transmit initial packets on. This allows us to offload address resolution onto the OS and not have to re-implement ARP. Once we hear back from the server, we know what all of the address fields are since the server responded with a completely filled-in ethernet/ip/udp packet. We then store the field on the path handle and send all future traffic over the AF_XDP socket instead.
Call-outs:
I've refactored the IO setup a bit to be in a central module, rather than copy/pasted in each qns command.
Testing:
The same testing applies as was done in #1765.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.