summaryrefslogtreecommitdiff
path: root/include/net/mptcp.h
diff options
context:
space:
mode:
authorChristoph Paasch <cpaasch@apple.com>2020-05-14 08:53:03 -0700
committerDavid S. Miller <davem@davemloft.net>2020-05-16 13:51:10 -0700
commita0c1d0eafd1ef1ada3b588ea205e5bc37ae0d8d9 (patch)
tree9e6c4e1406a00559b1dd4ef04cf502d65e5cb3e7 /include/net/mptcp.h
parent9efd6a3cecdde984d67e63d17fe6af53c7c50968 (diff)
downloadlwn-a0c1d0eafd1ef1ada3b588ea205e5bc37ae0d8d9.tar.gz
lwn-a0c1d0eafd1ef1ada3b588ea205e5bc37ae0d8d9.zip
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 <cpaasch@apple.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'include/net/mptcp.h')
-rw-r--r--include/net/mptcp.h5
1 files changed, 4 insertions, 1 deletions
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;