pub struct UdpCaps {
pub max_send_segments: usize,
pub max_recv_segments: usize,
pub ecn: bool,
pub may_fragment: bool,
}Expand description
Which offloads a socket has.
§Three answers, not one boolean
They degrade independently, and the stack that consumes them already
treats them so — max_transmit_segments, max_receive_segments and a
per-datagram ecn field are three separate questions on
quinn::AsyncUdpSocket, with may_fragment a fourth. Collapsing them
into one bool would be the mistake TcpOptsSupport exists not to make:
the caller’s decision differs per offload, so the report must too.
Measured on x86-64 Linux 7.0.0 for a plain std::net::UdpSocket:
max_send_segments = 64, max_recv_segments = 64, ecn = true,
may_fragment = false. Those are that kernel’s numbers, not this
crate’s: they are what the report exists to carry.
Fields§
§max_send_segments: usizeDatagrams one try_send may carry. 1 means no GSO.
max_recv_segments: usizeDatagrams one poll_recv slot may describe. 1 means no GRO.
ecn: boolWhether Datagrams::ecn is applied on send and
RecvMeta::ecn is filled in on receive.
may_fragment: boolWhether datagrams may be fragmented in flight — which makes path
MTU discovery unreliable. true is the pessimistic answer, so it is
the one in UdpCaps::NONE.
Implementations§
Source§impl UdpCaps
impl UdpCaps
Sourcepub const NONE: Self
pub const NONE: Self
A socket with no offloads at all, and the default for
UdpDatagrams::caps.
Note may_fragment: true — the worse answer, not the tidier one.
Every field here is the value that costs a forgetful implementer an
understatement rather than a promise it cannot keep, which is the
rule TcpOptsSupport::NONE established.