diff options
| author | Jakub Kicinski <kuba@kernel.org> | 2022-05-05 19:00:19 -0700 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2022-05-05 19:00:20 -0700 |
| commit | 949dfdcf343c1646d26ee0ef320d6b2a4a39af28 (patch) | |
| tree | 580059ce70376365ab585f2a7c2f3f7dfd8db6dc /include | |
| parent | 10b4a11fe70f295426fb4ebbb8b20370885c3806 (diff) | |
| parent | 38acb6260f60a7698c3a24db4df6ec1cf8f14c60 (diff) | |
| download | cachepc-linux-949dfdcf343c1646d26ee0ef320d6b2a4a39af28.tar.gz cachepc-linux-949dfdcf343c1646d26ee0ef320d6b2a4a39af28.zip | |
Merge branch 'mptcp-improve-mptcp-level-window-tracking'
Mat Martineau says:
====================
mptcp: Improve MPTCP-level window tracking
This series improves MPTCP receive window compliance with RFC 8684 and
helps increase throughput on high-speed links. Note that patch 3 makes a
change in tcp_output.c
For the details, Paolo says:
I've been chasing bad/unstable performance with multiple subflows
on very high speed links.
It looks like the root cause is due to the current mptcp-level
congestion window handling. There are apparently a few different
sub-issues:
- the rcv_wnd is not effectively shared on the tx side, as each
subflow takes in account only the value received by the underlaying
TCP connection. This is addressed in patch 1/5
- The mptcp-level offered wnd right edge is currently allowed to shrink.
Reading section 3.3.4.:
"""
The receive window is relative to the DATA_ACK. As in TCP, a
receiver MUST NOT shrink the right edge of the receive window (i.e.,
DATA_ACK + receive window). The receiver will use the data sequence
number to tell if a packet should be accepted at the connection
level.
"""
I read the above as we need to reflect window right-edge tracking
on the wire, see patch 4/5.
- The offered window right edge tracking can happen concurrently on
multiple subflows, but there is no mutex protection. We need an
additional atomic operation - still patch 4/5
This series additionally bumps a few new MIBs to track all the above
(ensure/observe that the suspected races actually take place).
I could not access again the host where the issue was so
noticeable, still in the current setup the tput changes from
[6-18] Gbps to 19Gbps very stable.
====================
Link: https://lore.kernel.org/r/20220504215408.349318-1-mathew.j.martineau@linux.intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include')
| -rw-r--r-- | include/net/mptcp.h | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/include/net/mptcp.h b/include/net/mptcp.h index 8b1afd6f5cc4..d4ec894ce67b 100644 --- a/include/net/mptcp.h +++ b/include/net/mptcp.h @@ -125,7 +125,7 @@ bool mptcp_established_options(struct sock *sk, struct sk_buff *skb, struct mptcp_out_options *opts); bool mptcp_incoming_options(struct sock *sk, struct sk_buff *skb); -void mptcp_write_options(__be32 *ptr, const struct tcp_sock *tp, +void mptcp_write_options(struct tcphdr *th, __be32 *ptr, struct tcp_sock *tp, struct mptcp_out_options *opts); void mptcp_diag_fill_info(struct mptcp_sock *msk, struct mptcp_info *info); |
