From a0c1d0eafd1ef1ada3b588ea205e5bc37ae0d8d9 Mon Sep 17 00:00:00 2001 From: Christoph Paasch Date: Thu, 14 May 2020 08:53:03 -0700 Subject: mptcp: Use 32-bit DATA_ACK when possible RFC8684 allows to send 32-bit DATA_ACKs as long as the peer is not sending 64-bit data-sequence numbers. The 64-bit DSN is only there for extreme scenarios when a very high throughput subflow is combined with a long-RTT subflow such that the high-throughput subflow wraps around the 32-bit sequence number space within an RTT of the high-RTT subflow. It is thus a rare scenario and we should try to use the 32-bit DATA_ACK instead as long as possible. It allows to reduce the TCP-option overhead by 4 bytes, thus makes space for an additional SACK-block. It also makes tcpdumps much easier to read when the DSN and DATA_ACK are both either 32 or 64-bit. Signed-off-by: Christoph Paasch Reviewed-by: Matthieu Baerts Signed-off-by: David S. Miller --- include/net/mptcp.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'include/net/mptcp.h') diff --git a/include/net/mptcp.h b/include/net/mptcp.h index c4a6ef4ba35b..46d0487d2b22 100644 --- a/include/net/mptcp.h +++ b/include/net/mptcp.h @@ -16,7 +16,10 @@ struct seq_file; /* MPTCP sk_buff extension data */ struct mptcp_ext { - u64 data_ack; + union { + u64 data_ack; + u32 data_ack32; + }; u64 data_seq; u32 subflow_seq; u16 data_len; -- cgit v1.2.3