2019-05-27 09:55:01 +03:00
/* SPDX-License-Identifier: GPL-2.0-or-later */
2005-04-17 02:20:36 +04:00
/*
* INET An implementation of the TCP / IP protocol suite for the LINUX
* operating system . INET is implemented using the BSD Socket
* interface as the means of communication with the user level .
*
* Definitions for the TCP module .
*
* Version : @ ( # ) tcp . h 1.0 .5 05 / 23 / 93
*
2005-05-06 03:16:16 +04:00
* Authors : Ross Biro
2005-04-17 02:20:36 +04:00
* Fred N . van Kempen , < waltje @ uWalt . NL . Mugnet . ORG >
*/
# ifndef _TCP_H
# define _TCP_H
# define FASTRETRANS_DEBUG 1
# include <linux/list.h>
# include <linux/tcp.h>
2011-11-24 05:12:59 +04:00
# include <linux/bug.h>
2005-04-17 02:20:36 +04:00
# include <linux/slab.h>
# include <linux/cache.h>
# include <linux/percpu.h>
2005-11-11 00:01:24 +03:00
# include <linux/skbuff.h>
2008-02-08 08:49:26 +03:00
# include <linux/cryptohash.h>
TCPCT part 1d: define TCP cookie option, extend existing struct's
Data structures are carefully composed to require minimal additions.
For example, the struct tcp_options_received cookie_plus variable fits
between existing 16-bit and 8-bit variables, requiring no additional
space (taking alignment into consideration). There are no additions to
tcp_request_sock, and only 1 pointer in tcp_sock.
This is a significantly revised implementation of an earlier (year-old)
patch that no longer applies cleanly, with permission of the original
author (Adam Langley):
http://thread.gmane.org/gmane.linux.network/102586
The principle difference is using a TCP option to carry the cookie nonce,
instead of a user configured offset in the data. This is more flexible and
less subject to user configuration error. Such a cookie option has been
suggested for many years, and is also useful without SYN data, allowing
several related concepts to use the same extension option.
"Re: SYN floods (was: does history repeat itself?)", September 9, 1996.
http://www.merit.net/mail.archives/nanog/1996-09/msg00235.html
"Re: what a new TCP header might look like", May 12, 1998.
ftp://ftp.isi.edu/end2end/end2end-interest-1998.mail
These functions will also be used in subsequent patches that implement
additional features.
Requires:
TCPCT part 1a: add request_values parameter for sending SYNACK
TCPCT part 1b: generate Responder Cookie secret
TCPCT part 1c: sysctl_tcp_cookie_size, socket option TCP_COOKIE_TRANSACTIONS
Signed-off-by: William.Allen.Simpson@gmail.com
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-12-02 21:17:05 +03:00
# include <linux/kref.h>
2014-02-27 02:02:48 +04:00
# include <linux/ktime.h>
2005-08-10 07:11:08 +04:00
# include <net/inet_connection_sock.h>
2005-08-10 07:44:40 +04:00
# include <net/inet_timewait_sock.h>
2005-08-10 07:00:51 +04:00
# include <net/inet_hashtables.h>
2005-04-17 02:20:36 +04:00
# include <net/checksum.h>
[NET] Generalise TCP's struct open_request minisock infrastructure
Kept this first changeset minimal, without changing existing names to
ease peer review.
Basicaly tcp_openreq_alloc now receives the or_calltable, that in turn
has two new members:
->slab, that replaces tcp_openreq_cachep
->obj_size, to inform the size of the openreq descendant for
a specific protocol
The protocol specific fields in struct open_request were moved to a
class hierarchy, with the things that are common to all connection
oriented PF_INET protocols in struct inet_request_sock, the TCP ones
in tcp_request_sock, that is an inet_request_sock, that is an
open_request.
I.e. this uses the same approach used for the struct sock class
hierarchy, with sk_prot indicating if the protocol wants to use the
open_request infrastructure by filling in sk_prot->rsk_prot with an
or_calltable.
Results? Performance is improved and TCP v4 now uses only 64 bytes per
open request minisock, down from 96 without this patch :-)
Next changeset will rename some of the structs, fields and functions
mentioned above, struct or_calltable is way unclear, better name it
struct request_sock_ops, s/struct open_request/struct request_sock/g,
etc.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-06-19 09:46:52 +04:00
# include <net/request_sock.h>
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
# include <net/sock_reuseport.h>
2005-04-17 02:20:36 +04:00
# include <net/sock.h>
# include <net/snmp.h>
# include <net/ip.h>
2005-08-10 07:08:28 +04:00
# include <net/tcp_states.h>
2007-05-27 13:04:16 +04:00
# include <net/inet_ecn.h>
2009-05-04 22:11:01 +04:00
# include <net/dst.h>
2020-01-09 18:59:20 +03:00
# include <net/mptcp.h>
2005-08-10 07:08:28 +04:00
2005-04-17 02:20:36 +04:00
# include <linux/seq_file.h>
2011-12-12 01:47:02 +04:00
# include <linux/memcontrol.h>
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
# include <linux/bpf-cgroup.h>
2019-06-20 00:46:28 +03:00
# include <linux/siphash.h>
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
2005-08-10 07:07:35 +04:00
extern struct inet_hashinfo tcp_hashinfo ;
2005-04-17 02:20:36 +04:00
2008-11-26 08:17:14 +03:00
extern struct percpu_counter tcp_orphan_count ;
2013-09-23 22:33:32 +04:00
void tcp_time_wait ( struct sock * sk , int state , int timeo ) ;
2005-04-17 02:20:36 +04:00
# define MAX_TCP_HEADER (128 + MAX_HEADER)
2008-07-19 11:04:31 +04:00
# define MAX_TCP_OPTION_SPACE 40
2019-05-18 03:17:22 +03:00
# define TCP_MIN_SND_MSS 48
# define TCP_MIN_GSO_SIZE (TCP_MIN_SND_MSS - MAX_TCP_OPTION_SPACE)
2005-04-17 02:20:36 +04:00
2014-10-20 13:15:50 +04:00
/*
2005-04-17 02:20:36 +04:00
* Never offer a window over 32767 without using window scaling . Some
2014-10-20 13:15:50 +04:00
* poor stacks do signed 16 bit maths !
2005-04-17 02:20:36 +04:00
*/
# define MAX_TCP_WINDOW 32767U
/* Minimal accepted MSS. It is (60+60+8) - (20+20). */
# define TCP_MIN_MSS 88U
2019-08-08 02:52:30 +03:00
/* The initial MTU to use for probing */
2015-03-06 06:18:22 +03:00
# define TCP_BASE_MSS 1024
2006-03-21 04:53:41 +03:00
2015-03-06 06:18:24 +03:00
/* probing interval, default to 10 minutes as per RFC4821 */
# define TCP_PROBE_INTERVAL 600
2015-03-06 06:18:23 +03:00
/* Specify interval when tcp mtu probing will stop */
# define TCP_PROBE_THRESHOLD 8
2005-04-17 02:20:36 +04:00
/* After receiving this amount of duplicate ACKs fast retransmit starts. */
# define TCP_FASTRETRANS_THRESH 3
/* Maximal number of ACKs sent quickly to accelerate slow-start. */
# define TCP_MAX_QUICKACKS 16U
2017-04-04 16:09:48 +03:00
/* Maximal number of window scale according to RFC1323 */
# define TCP_MAX_WSCALE 14U
2005-04-17 02:20:36 +04:00
/* urg_data states */
# define TCP_URG_VALID 0x0100
# define TCP_URG_NOTYET 0x0200
# define TCP_URG_READ 0x0400
# define TCP_RETR1 3 / *
* This is how many retries it does before it
* tries to figure out if the gateway is
* down . Minimal RFC value is 3 ; it corresponds
* to ~ 3 sec - 8 min depending on RTO .
*/
# define TCP_RETR2 15 / *
* This should take at least
* 90 minutes to time out .
* RFC1122 says that the limit is 100 sec .
* 15 is ~ 13 - 30 min depending on RTO .
*/
2012-08-31 06:48:31 +04:00
# define TCP_SYN_RETRIES 6 / * This is how many retries are done
* when active opening a connection .
* RFC1122 says the minimum retry MUST
* be at least 180 secs . Nevertheless
* this value is corresponding to
* 63 secs of retransmission with the
* current initial RTO .
*/
2005-04-17 02:20:36 +04:00
2012-08-31 06:48:31 +04:00
# define TCP_SYNACK_RETRIES 5 / * This is how may retries are done
* when passive opening a connection .
* This is corresponding to 31 secs of
* retransmission with the current
* initial RTO .
*/
2005-04-17 02:20:36 +04:00
# define TCP_TIMEWAIT_LEN (60*HZ) / * how long to wait to destroy TIME-WAIT
* state , about 60 seconds */
# define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN
/* BSD style FIN_WAIT2 deadlock breaker.
* It used to be 3 min , new value is 60 sec ,
* to combine FIN - WAIT - 2 timeout with
* TIME - WAIT timer .
*/
# define TCP_DELACK_MAX ((unsigned)(HZ / 5)) /* maximal time to delay before sending an ACK */
# if HZ >= 100
# define TCP_DELACK_MIN ((unsigned)(HZ / 25)) /* minimal time to delay before sending an ACK */
# define TCP_ATO_MIN ((unsigned)(HZ / 25))
# else
# define TCP_DELACK_MIN 4U
# define TCP_ATO_MIN 4U
# endif
# define TCP_RTO_MAX ((unsigned)(120*HZ))
# define TCP_RTO_MIN ((unsigned)(HZ / 5))
2017-07-20 01:41:26 +03:00
# define TCP_TIMEOUT_MIN (2U) /* Min timeout for TCP timers in jiffies */
2012-04-12 23:48:40 +04:00
# define TCP_TIMEOUT_INIT ((unsigned)(1*HZ)) /* RFC6298 2.1 initial RTO value */
2011-06-08 15:08:38 +04:00
# define TCP_TIMEOUT_FALLBACK ((unsigned)(3*HZ)) / * RFC 1122 initial RTO value, now
* used as a fallback RTO for the
* initial data transmission if no
* valid RTT sample has been acquired ,
* most likely due to retrans in 3 WHS .
*/
2005-04-17 02:20:36 +04:00
# define TCP_RESOURCE_PROBE_INTERVAL ((unsigned)(HZ / 2U)) / * Maximal interval between probes
* for local resources .
*/
# define TCP_KEEPALIVE_TIME (120*60*HZ) /* two hours */
# define TCP_KEEPALIVE_PROBES 9 /* Max of 9 keepalive probes */
# define TCP_KEEPALIVE_INTVL (75*HZ)
# define MAX_TCP_KEEPIDLE 32767
# define MAX_TCP_KEEPINTVL 32767
# define MAX_TCP_KEEPCNT 127
# define MAX_TCP_SYNCNT 127
# define TCP_SYNQ_INTERVAL (HZ / 5) /* Period of SYNACK timer */
# define TCP_PAWS_24DAYS (60 * 60 * 24 * 24)
# define TCP_PAWS_MSL 60 / * Per-host timestamps are invalidated
* after this time . It should be equal
* ( or greater than ) TCP_TIMEWAIT_LEN
* to provide reliability equal to one
* provided by timewait state .
*/
# define TCP_PAWS_WINDOW 1 / * Replay window for per-host
* timestamps . It must be less than
* minimal timewait lifetime .
*/
/*
* TCP option
*/
2014-10-20 13:15:50 +04:00
2005-04-17 02:20:36 +04:00
# define TCPOPT_NOP 1 /* Padding */
# define TCPOPT_EOL 0 /* End of options */
# define TCPOPT_MSS 2 /* Segment size negotiating */
# define TCPOPT_WINDOW 3 /* Window scaling */
# define TCPOPT_SACK_PERM 4 /* SACK Permitted */
# define TCPOPT_SACK 5 /* SACK Block */
# define TCPOPT_TIMESTAMP 8 /* Better RTT estimations/PAWS */
2006-11-15 06:07:45 +03:00
# define TCPOPT_MD5SIG 19 /* MD5 Signature (RFC2385) */
2020-01-09 18:59:17 +03:00
# define TCPOPT_MPTCP 30 /* Multipath TCP (RFC6824) */
2015-04-07 00:37:26 +03:00
# define TCPOPT_FASTOPEN 34 /* Fast open (RFC7413) */
2012-07-19 10:43:05 +04:00
# define TCPOPT_EXP 254 /* Experimental */
/* Magic number to be after the option value for sharing TCP
* experimental options . See draft - ietf - tcpm - experimental - options - 00. txt
*/
# define TCPOPT_FASTOPEN_MAGIC 0xF989
2017-10-25 12:01:45 +03:00
# define TCPOPT_SMC_MAGIC 0xE2D4C3D9
2005-04-17 02:20:36 +04:00
/*
* TCP option lengths
*/
# define TCPOLEN_MSS 4
# define TCPOLEN_WINDOW 3
# define TCPOLEN_SACK_PERM 2
# define TCPOLEN_TIMESTAMP 10
2006-11-15 06:07:45 +03:00
# define TCPOLEN_MD5SIG 18
2015-04-07 00:37:26 +03:00
# define TCPOLEN_FASTOPEN_BASE 2
2012-07-19 10:43:05 +04:00
# define TCPOLEN_EXP_FASTOPEN_BASE 4
2017-10-25 12:01:45 +03:00
# define TCPOLEN_EXP_SMC_BASE 6
2005-04-17 02:20:36 +04:00
/* But this is what stacks really send out. */
# define TCPOLEN_TSTAMP_ALIGNED 12
# define TCPOLEN_WSCALE_ALIGNED 4
# define TCPOLEN_SACKPERM_ALIGNED 4
# define TCPOLEN_SACK_BASE 2
# define TCPOLEN_SACK_BASE_ALIGNED 4
# define TCPOLEN_SACK_PERBLOCK 8
2006-11-15 06:07:45 +03:00
# define TCPOLEN_MD5SIG_ALIGNED 20
2008-07-19 11:04:31 +04:00
# define TCPOLEN_MSS_ALIGNED 4
2017-10-25 12:01:45 +03:00
# define TCPOLEN_EXP_SMC_BASE_ALIGNED 8
2005-04-17 02:20:36 +04:00
/* Flags in tp->nonagle */
# define TCP_NAGLE_OFF 1 /* Nagle's algo is disabled */
# define TCP_NAGLE_CORK 2 /* Socket is corked */
2005-11-11 04:13:47 +03:00
# define TCP_NAGLE_PUSH 4 /* Cork is overridden for already queued data */
2005-04-17 02:20:36 +04:00
2010-02-18 05:47:01 +03:00
/* TCP thin-stream limits */
# define TCP_THIN_LINEAR_RETRIES 6 /* After 6 linear retries, do exp. backoff */
2016-01-28 00:54:06 +03:00
/* TCP initial congestion window as per rfc6928 */
2011-02-03 04:05:11 +03:00
# define TCP_INIT_CWND 10
2012-07-19 10:43:09 +04:00
/* Bit Flags for sysctl_tcp_fastopen */
# define TFO_CLIENT_ENABLE 1
2012-08-31 16:29:11 +04:00
# define TFO_SERVER_ENABLE 2
2012-07-19 10:43:11 +04:00
# define TFO_CLIENT_NO_COOKIE 4 /* Data in SYN w/o cookie option */
2012-07-19 10:43:09 +04:00
2012-08-31 16:29:11 +04:00
/* Accept SYN data w/o any cookie option */
# define TFO_SERVER_COOKIE_NOT_REQD 0x200
/* Force enable TFO on all listeners, i.e., not requiring the
2016-08-23 03:17:54 +03:00
* TCP_FASTOPEN socket option .
2012-08-31 16:29:11 +04:00
*/
# define TFO_SERVER_WO_SOCKOPT1 0x400
2005-08-10 07:44:40 +04:00
2005-04-17 02:20:36 +04:00
/* sysctl variables for tcp */
extern int sysctl_tcp_max_orphans ;
2013-10-20 03:25:36 +04:00
extern long sysctl_tcp_mem [ 3 ] ;
2017-10-27 07:54:57 +03:00
2017-01-13 09:11:36 +03:00
# define TCP_RACK_LOSS_DETECTION 0x1 /* Use RACK to detect losses */
2017-11-04 02:38:48 +03:00
# define TCP_RACK_STATIC_REO_WND 0x2 /* Use static RACK reo wnd */
tcp: support DUPACK threshold in RACK
This patch adds support for the classic DUPACK threshold rule
(#DupThresh) in RACK.
When the number of packets SACKed is greater or equal to the
threshold, RACK sets the reordering window to zero which would
immediately mark all the unsacked packets below the highest SACKed
sequence lost. Since this approach is known to not work well with
reordering, RACK only uses it if no reordering has been observed.
The DUPACK threshold rule is a particularly useful extension to the
fast recoveries triggered by RACK reordering timer. For example
data-center transfers where the RTT is much smaller than a timer
tick, or high RTT path where the default RTT/4 may take too long.
Note that this patch differs slightly from RFC6675. RFC6675
considers a packet lost when at least #DupThresh higher-sequence
packets are SACKed.
With RACK, for connections that have seen reordering, RACK
continues to use a dynamically-adaptive time-based reordering
window to detect losses. But for connections on which we have not
yet seen reordering, this patch considers a packet lost when at
least one higher sequence packet is SACKed and the total number
of SACKed packets is at least DupThresh. For example, suppose a
connection has not seen reordering, and sends 10 packets, and
packets 3, 5, 7 are SACKed. RFC6675 considers packets 1 and 2
lost. RACK considers packets 1, 2, 4, 6 lost.
There is some small risk of spurious retransmits here due to
reordering. However, this is mostly limited to the first flight of
a connection on which the sender receives SACKs from reordering.
And RFC 6675 and FACK loss detection have a similar risk on the
first flight with reordering (it's just that the risk of spurious
retransmits from reordering was slightly narrower for those older
algorithms due to the margin of 3*MSS).
Also the minimum reordering window is reduced from 1 msec to 0
to recover quicker on short RTT transfers. Therefore RACK is more
aggressive in marking packets lost during recovery to reduce the
reordering window timeouts.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Soheil Hassas Yeganeh <soheil@google.com>
Reviewed-by: Priyaranjan Jha <priyarjha@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-17 02:40:10 +03:00
# define TCP_RACK_NO_DUPTHRESH 0x4 /* Do not use DUPACK threshold in RACK */
2017-01-13 09:11:36 +03:00
2010-11-10 02:24:26 +03:00
extern atomic_long_t tcp_memory_allocated ;
2008-11-26 08:16:35 +03:00
extern struct percpu_counter tcp_sockets_allocated ;
2017-06-07 23:29:12 +03:00
extern unsigned long tcp_memory_pressure ;
2005-04-17 02:20:36 +04:00
2015-05-15 22:39:27 +03:00
/* optimized version of sk_under_memory_pressure() for TCP sockets */
static inline bool tcp_under_memory_pressure ( const struct sock * sk )
{
2016-01-15 02:21:17 +03:00
if ( mem_cgroup_sockets_enabled & & sk - > sk_memcg & &
mem_cgroup_under_socket_pressure ( sk - > sk_memcg ) )
net: tcp_memcontrol: sanitize tcp memory accounting callbacks
There won't be a tcp control soft limit, so integrating the memcg code
into the global skmem limiting scheme complicates things unnecessarily.
Replace this with simple and clear charge and uncharge calls--hidden
behind a jump label--to account skb memory.
Note that this is not purely aesthetic: as a result of shoehorning the
per-memcg code into the same memory accounting functions that handle the
global level, the old code would compare the per-memcg consumption
against the smaller of the per-memcg limit and the global limit. This
allowed the total consumption of multiple sockets to exceed the global
limit, as long as the individual sockets stayed within bounds. After
this change, the code will always compare the per-memcg consumption to
the per-memcg limit, and the global consumption to the global limit, and
thus close this loophole.
Without a soft limit, the per-memcg memory pressure state in sockets is
generally questionable. However, we did it until now, so we continue to
enter it when the hard limit is hit, and packets are dropped, to let
other sockets in the cgroup know that they shouldn't grow their transmit
windows, either. However, keep it simple in the new callback model and
leave memory pressure lazily when the next packet is accepted (as
opposed to doing it synchroneously when packets are processed). When
packets are dropped, network performance will already be in the toilet,
so that should be a reasonable trade-off.
As described above, consumption is now checked on the per-memcg level
and the global level separately. Likewise, memory pressure states are
maintained on both the per-memcg level and the global level, and a
socket is considered under pressure when either level asserts as much.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-01-15 02:21:14 +03:00
return true ;
2015-05-15 22:39:27 +03:00
2019-10-10 01:10:15 +03:00
return READ_ONCE ( tcp_memory_pressure ) ;
2015-05-15 22:39:27 +03:00
}
2005-04-17 02:20:36 +04:00
/*
* The next routines deal with comparing 32 bit unsigned ints
* and worry about wraparound ( automatic with unsigned arithmetic ) .
*/
2012-05-17 03:15:34 +04:00
static inline bool before ( __u32 seq1 , __u32 seq2 )
2005-04-17 02:20:36 +04:00
{
2007-01-04 23:25:16 +03:00
return ( __s32 ) ( seq1 - seq2 ) < 0 ;
2005-04-17 02:20:36 +04:00
}
[TCP]: Fix ambiguity in the `before' relation.
While looking at DCCP sequence numbers, I stumbled over a problem with
the following definition of before in tcp.h:
static inline int before(__u32 seq1, __u32 seq2)
{
return (__s32)(seq1-seq2) < 0;
}
Problem: This definition suffers from an an ambiguity, i.e. always
before(a, (a + 2^31) % 2^32)) = 1
before((a + 2^31) % 2^32), a) = 1
In text: when the difference between a and b amounts to 2^31,
a is always considered `before' b, the function can not decide.
The reason is that implicitly 0 is `before' 1 ... 2^31-1 ... 2^31
Solution: There is a simple fix, by defining before in such a way that
0 is no longer `before' 2^31, i.e. 0 `before' 1 ... 2^31-1
By not using the middle between 0 and 2^32, before can be made
unambiguous.
This is achieved by testing whether seq2-seq1 > 0 (using signed
32-bit arithmetic).
I attach a patch to codify this. Also the `after' relation is basically
a redefinition of `before', it is now defined as a macro after before.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-12-20 21:25:55 +03:00
# define after(seq2, seq1) before(seq1, seq2)
2005-04-17 02:20:36 +04:00
/* is s2<=s1<=s3 ? */
2012-05-17 03:15:34 +04:00
static inline bool between ( __u32 seq1 , __u32 seq2 , __u32 seq3 )
2005-04-17 02:20:36 +04:00
{
return seq3 - seq2 > = seq1 - seq2 ;
}
2012-01-31 02:16:06 +04:00
static inline bool tcp_out_of_memory ( struct sock * sk )
{
if ( sk - > sk_wmem_queued > SOCK_MIN_SNDBUF & &
sk_memory_allocated ( sk ) > sk_prot_mem_limits ( sk , 2 ) )
return true ;
return false ;
}
2015-05-15 22:39:26 +03:00
void sk_forced_mem_schedule ( struct sock * sk , int size ) ;
2010-08-25 13:27:49 +04:00
static inline bool tcp_too_many_orphans ( struct sock * sk , int shift )
2007-05-30 00:19:18 +04:00
{
2010-08-25 13:27:49 +04:00
struct percpu_counter * ocp = sk - > sk_prot - > orphan_count ;
int orphans = percpu_counter_read_positive ( ocp ) ;
if ( orphans < < shift > sysctl_tcp_max_orphans ) {
orphans = percpu_counter_sum_positive ( ocp ) ;
if ( orphans < < shift > sysctl_tcp_max_orphans )
return true ;
}
return false ;
2007-05-30 00:19:18 +04:00
}
2005-04-17 02:20:36 +04:00
2013-09-23 22:33:32 +04:00
bool tcp_check_oom ( struct sock * sk , int shift ) ;
2012-01-31 02:16:06 +04:00
2009-04-19 13:43:48 +04:00
2005-04-17 02:20:36 +04:00
extern struct proto tcp_prot ;
2008-07-18 15:02:08 +04:00
# define TCP_INC_STATS(net, field) SNMP_INC_STATS((net)->mib.tcp_statistics, field)
2016-04-28 02:44:43 +03:00
# define __TCP_INC_STATS(net, field) __SNMP_INC_STATS((net)->mib.tcp_statistics, field)
2008-07-18 15:02:08 +04:00
# define TCP_DEC_STATS(net, field) SNMP_DEC_STATS((net)->mib.tcp_statistics, field)
2010-04-22 11:00:24 +04:00
# define TCP_ADD_STATS(net, field, val) SNMP_ADD_STATS((net)->mib.tcp_statistics, field, val)
2005-04-17 02:20:36 +04:00
2013-09-23 22:33:32 +04:00
void tcp_tasklet_init ( void ) ;
2018-11-08 14:19:21 +03:00
int tcp_v4_err ( struct sk_buff * skb , u32 ) ;
2013-09-23 22:33:32 +04:00
void tcp_shutdown ( struct sock * sk , int how ) ;
2017-09-28 16:51:36 +03:00
int tcp_v4_early_demux ( struct sk_buff * skb ) ;
2013-09-23 22:33:32 +04:00
int tcp_v4_rcv ( struct sk_buff * skb ) ;
int tcp_v4_tw_remember_stamp ( struct inet_timewait_sock * tw ) ;
2015-03-02 10:37:48 +03:00
int tcp_sendmsg ( struct sock * sk , struct msghdr * msg , size_t size ) ;
2017-07-29 02:22:41 +03:00
int tcp_sendmsg_locked ( struct sock * sk , struct msghdr * msg , size_t size ) ;
2013-09-23 22:33:32 +04:00
int tcp_sendpage ( struct sock * sk , struct page * page , int offset , size_t size ,
int flags ) ;
2017-07-29 02:22:41 +03:00
int tcp_sendpage_locked ( struct sock * sk , struct page * page , int offset ,
size_t size , int flags ) ;
2017-06-14 21:37:26 +03:00
ssize_t do_tcp_sendpages ( struct sock * sk , struct page * page , int offset ,
size_t size , int flags ) ;
2020-01-09 18:59:21 +03:00
int tcp_send_mss ( struct sock * sk , int * size_goal , int flags ) ;
void tcp_push ( struct sock * sk , int flags , int mss_now , int nonagle ,
int size_goal ) ;
2013-09-23 22:33:32 +04:00
void tcp_release_cb ( struct sock * sk ) ;
void tcp_wfree ( struct sk_buff * skb ) ;
void tcp_write_timer_handler ( struct sock * sk ) ;
void tcp_delack_timer_handler ( struct sock * sk ) ;
int tcp_ioctl ( struct sock * sk , int cmd , unsigned long arg ) ;
2015-09-29 17:42:41 +03:00
int tcp_rcv_state_process ( struct sock * sk , struct sk_buff * skb ) ;
2018-05-29 18:27:31 +03:00
void tcp_rcv_established ( struct sock * sk , struct sk_buff * skb ) ;
2013-09-23 22:33:32 +04:00
void tcp_rcv_space_adjust ( struct sock * sk ) ;
int tcp_twsk_unique ( struct sock * sk , struct sock * sktw , void * twp ) ;
void tcp_twsk_destructor ( struct sock * sk ) ;
ssize_t tcp_splice_read ( struct socket * sk , loff_t * ppos ,
struct pipe_inode_info * pipe , size_t len ,
unsigned int flags ) ;
2007-11-07 10:30:13 +03:00
tcp: do not delay ACK in DCTCP upon CE status change
Per DCTCP RFC8257 (Section 3.2) the ACK reflecting the CE status change
has to be sent immediately so the sender can respond quickly:
""" When receiving packets, the CE codepoint MUST be processed as follows:
1. If the CE codepoint is set and DCTCP.CE is false, set DCTCP.CE to
true and send an immediate ACK.
2. If the CE codepoint is not set and DCTCP.CE is true, set DCTCP.CE
to false and send an immediate ACK.
"""
Previously DCTCP implementation may continue to delay the ACK. This
patch fixes that to implement the RFC by forcing an immediate ACK.
Tested with this packetdrill script provided by Larry Brakmo
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, "dctcp", 5) = 0
0.000 bind(3, ..., ...) = 0
0.000 listen(3, 1) = 0
0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
0.110 < [ect0] . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_SOCKET, SO_DEBUG, [1], 4) = 0
0.200 < [ect0] . 1:1001(1000) ack 1 win 257
0.200 > [ect01] . 1:1(0) ack 1001
0.200 write(4, ..., 1) = 1
0.200 > [ect01] P. 1:2(1) ack 1001
0.200 < [ect0] . 1001:2001(1000) ack 2 win 257
+0.005 < [ce] . 2001:3001(1000) ack 2 win 257
+0.000 > [ect01] . 2:2(0) ack 2001
// Previously the ACK below would be delayed by 40ms
+0.000 > [ect01] E. 2:2(0) ack 3001
+0.500 < F. 9501:9501(0) ack 4 win 257
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-18 23:56:36 +03:00
void tcp_enter_quickack_mode ( struct sock * sk , unsigned int max_quickacks ) ;
2005-08-10 07:10:42 +04:00
static inline void tcp_dec_quickack_mode ( struct sock * sk ,
const unsigned int pkts )
2005-04-17 02:20:36 +04:00
{
2005-08-10 07:10:42 +04:00
struct inet_connection_sock * icsk = inet_csk ( sk ) ;
2005-07-06 02:17:45 +04:00
2005-08-10 07:10:42 +04:00
if ( icsk - > icsk_ack . quick ) {
if ( pkts > = icsk - > icsk_ack . quick ) {
icsk - > icsk_ack . quick = 0 ;
2005-07-06 02:17:45 +04:00
/* Leaving quickack mode we deflate ATO. */
2005-08-10 07:10:42 +04:00
icsk - > icsk_ack . ato = TCP_ATO_MIN ;
2005-07-06 02:17:45 +04:00
} else
2005-08-10 07:10:42 +04:00
icsk - > icsk_ack . quick - = pkts ;
2005-04-17 02:20:36 +04:00
}
}
2007-05-27 13:04:16 +04:00
# define TCP_ECN_OK 1
# define TCP_ECN_QUEUE_CWR 2
# define TCP_ECN_DEMAND_CWR 4
2011-09-23 00:02:19 +04:00
# define TCP_ECN_SEEN 8
2007-05-27 13:04:16 +04:00
2009-11-03 06:26:03 +03:00
enum tcp_tw_status {
2005-04-17 02:20:36 +04:00
TCP_TW_SUCCESS = 0 ,
TCP_TW_RST = 1 ,
TCP_TW_ACK = 2 ,
TCP_TW_SYN = 3
} ;
2013-09-23 22:33:32 +04:00
enum tcp_tw_status tcp_timewait_state_process ( struct inet_timewait_sock * tw ,
struct sk_buff * skb ,
const struct tcphdr * th ) ;
struct sock * tcp_check_req ( struct sock * sk , struct sk_buff * skb ,
2018-02-13 17:14:12 +03:00
struct request_sock * req , bool fastopen ,
bool * lost_race ) ;
2013-09-23 22:33:32 +04:00
int tcp_child_process ( struct sock * parent , struct sock * child ,
struct sk_buff * skb ) ;
tcp: reduce spurious retransmits due to transient SACK reneging
This commit reduces spurious retransmits due to apparent SACK reneging
by only reacting to SACK reneging that persists for a short delay.
When a sequence space hole at snd_una is filled, some TCP receivers
send a series of ACKs as they apparently scan their out-of-order queue
and cumulatively ACK all the packets that have now been consecutiveyly
received. This is essentially misbehavior B in "Misbehaviors in TCP
SACK generation" ACM SIGCOMM Computer Communication Review, April
2011, so we suspect that this is from several common OSes (Windows
2000, Windows Server 2003, Windows XP). However, this issue has also
been seen in other cases, e.g. the netdev thread "TCP being hoodwinked
into spurious retransmissions by lack of timestamps?" from March 2014,
where the receiver was thought to be a BSD box.
Since snd_una would temporarily be adjacent to a previously SACKed
range in these scenarios, this receiver behavior triggered the Linux
SACK reneging code path in the sender. This led the sender to clear
the SACK scoreboard, enter CA_Loss, and spuriously retransmit
(potentially) every packet from the entire write queue at line rate
just a few milliseconds before the ACK for each packet arrives at the
sender.
To avoid such situations, now when a sender sees apparent reneging it
does not yet retransmit, but rather adjusts the RTO timer to give the
receiver a little time (max(RTT/2, 10ms)) to send us some more ACKs
that will restore sanity to the SACK scoreboard. If the reneging
persists until this RTO then, as before, we clear the SACK scoreboard
and enter CA_Loss.
A 10ms delay tolerates a receiver sending such a stream of ACKs at
56Kbit/sec. And to allow for receivers with slower or more congested
paths, we wait for at least RTT/2.
We validated the resulting max(RTT/2, 10ms) delay formula with a mix
of North American and South American Google web server traffic, and
found that for ACKs displaying transient reneging:
(1) 90% of inter-ACK delays were less than 10ms
(2) 99% of inter-ACK delays were less than RTT/2
In tests on Google web servers this commit reduced reneging events by
75%-90% (as measured by the TcpExtTCPSACKReneging counter), without
any measurable impact on latency for user HTTP and SPDY requests.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-08-05 03:12:29 +04:00
void tcp_enter_loss ( struct sock * sk ) ;
2017-01-13 09:11:33 +03:00
void tcp_cwnd_reduction ( struct sock * sk , int newly_acked_sacked , int flag ) ;
2013-09-23 22:33:32 +04:00
void tcp_clear_retrans ( struct tcp_sock * tp ) ;
void tcp_update_metrics ( struct sock * sk ) ;
void tcp_init_metrics ( struct sock * sk ) ;
void tcp_metrics_init ( void ) ;
2017-03-15 23:30:45 +03:00
bool tcp_peer_is_proven ( struct request_sock * req , struct dst_entry * dst ) ;
2013-09-23 22:33:32 +04:00
void tcp_close ( struct sock * sk , long timeout ) ;
void tcp_init_sock ( struct sock * sk ) ;
tcp: uniform the set up of sockets after successful connection
Currently in the TCP code, the initialization sequence for cached
metrics, congestion control, BPF, etc, after successful connection
is very inconsistent. This introduces inconsistent bevhavior and is
prone to bugs. The current call sequence is as follows:
(1) for active case (tcp_finish_connect() case):
tcp_mtup_init(sk);
icsk->icsk_af_ops->rebuild_header(sk);
tcp_init_metrics(sk);
tcp_call_bpf(sk, BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB);
tcp_init_congestion_control(sk);
tcp_init_buffer_space(sk);
(2) for passive case (tcp_rcv_state_process() TCP_SYN_RECV case):
icsk->icsk_af_ops->rebuild_header(sk);
tcp_call_bpf(sk, BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB);
tcp_init_congestion_control(sk);
tcp_mtup_init(sk);
tcp_init_buffer_space(sk);
tcp_init_metrics(sk);
(3) for TFO passive case (tcp_fastopen_create_child()):
inet_csk(child)->icsk_af_ops->rebuild_header(child);
tcp_init_congestion_control(child);
tcp_mtup_init(child);
tcp_init_metrics(child);
tcp_call_bpf(child, BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB);
tcp_init_buffer_space(child);
This commit uniforms the above functions to have the following sequence:
tcp_mtup_init(sk);
icsk->icsk_af_ops->rebuild_header(sk);
tcp_init_metrics(sk);
tcp_call_bpf(sk, BPF_SOCK_OPS_ACTIVE/PASSIVE_ESTABLISHED_CB);
tcp_init_congestion_control(sk);
tcp_init_buffer_space(sk);
This sequence is the same as the (1) active case. We pick this sequence
because this order correctly allows BPF to override the settings
including congestion control module and initial cwnd, etc from
the route, and then allows the CC module to see those settings.
Suggested-by: Neal Cardwell <ncardwell@google.com>
Tested-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-04 20:03:44 +03:00
void tcp_init_transfer ( struct sock * sk , int bpf_op ) ;
2018-06-28 19:43:44 +03:00
__poll_t tcp_poll ( struct file * file , struct socket * sock ,
struct poll_table_struct * wait ) ;
2013-09-23 22:33:32 +04:00
int tcp_getsockopt ( struct sock * sk , int level , int optname ,
char __user * optval , int __user * optlen ) ;
int tcp_setsockopt ( struct sock * sk , int level , int optname ,
char __user * optval , unsigned int optlen ) ;
int compat_tcp_getsockopt ( struct sock * sk , int level , int optname ,
2010-07-11 00:41:06 +04:00
char __user * optval , int __user * optlen ) ;
2013-09-23 22:33:32 +04:00
int compat_tcp_setsockopt ( struct sock * sk , int level , int optname ,
2010-07-11 00:41:06 +04:00
char __user * optval , unsigned int optlen ) ;
2013-09-23 22:33:32 +04:00
void tcp_set_keepalive ( struct sock * sk , int val ) ;
2015-03-22 20:22:19 +03:00
void tcp_syn_ack_timeout ( const struct request_sock * req ) ;
2015-03-02 10:37:48 +03:00
int tcp_recvmsg ( struct sock * sk , struct msghdr * msg , size_t len , int nonblock ,
int flags , int * addr_len ) ;
2018-04-16 20:33:35 +03:00
int tcp_set_rcvlowat ( struct sock * sk , int val ) ;
tcp: avoid extra wakeups for SO_RCVLOWAT users
SO_RCVLOWAT is properly handled in tcp_poll(), so that POLLIN is only
generated when enough bytes are available in receive queue, after
David change (commit c7004482e8dc "tcp: Respect SO_RCVLOWAT in tcp_poll().")
But TCP still calls sk->sk_data_ready() for each chunk added in receive
queue, meaning thread is awaken, and goes back to sleep shortly after.
Tested:
tcp_mmap test program, receiving 32768 MB of data with SO_RCVLOWAT set to 512KB
-> Should get ~2 wakeups (c-switches) per MB, regardless of how many
(tiny or big) packets were received.
High speed (mostly full size GRO packets)
received 32768 MB (100 % mmap'ed) in 8.03112 s, 34.2266 Gbit,
cpu usage user:0.037 sys:1.404, 43.9758 usec per MB, 65497 c-switches
received 32768 MB (99.9954 % mmap'ed) in 7.98453 s, 34.4263 Gbit,
cpu usage user:0.03 sys:1.422, 44.3115 usec per MB, 65485 c-switches
Low speed (sender is ratelimited and sends 1-MSS at a time, so GRO is not helping)
received 22474.5 MB (100 % mmap'ed) in 6015.35 s, 0.0313414 Gbit,
cpu usage user:0.05 sys:1.586, 72.7952 usec per MB, 44950 c-switches
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-16 20:33:37 +03:00
void tcp_data_ready ( struct sock * sk ) ;
2019-01-17 13:03:14 +03:00
# ifdef CONFIG_MMU
tcp: implement mmap() for zero copy receive
Some networks can make sure TCP payload can exactly fit 4KB pages,
with well chosen MSS/MTU and architectures.
Implement mmap() system call so that applications can avoid
copying data without complex splice() games.
Note that a successful mmap( X bytes) on TCP socket is consuming
bytes, as if recvmsg() has been done. (tp->copied += X)
Only PROT_READ mappings are accepted, as skb page frags
are fundamentally shared and read only.
If tcp_mmap() finds data that is not a full page, or a patch of
urgent data, -EINVAL is returned, no bytes are consumed.
Application must fallback to recvmsg() to read the problematic sequence.
mmap() wont block, regardless of socket being in blocking or
non-blocking mode. If not enough bytes are in receive queue,
mmap() would return -EAGAIN, or -EIO if socket is in a state
where no other bytes can be added into receive queue.
An application might use SO_RCVLOWAT, poll() and/or ioctl( FIONREAD)
to efficiently use mmap()
On the sender side, MSG_EOR might help to clearly separate unaligned
headers and 4K-aligned chunks if necessary.
Tested:
mlx4 (cx-3) 40Gbit NIC, with tcp_mmap program provided in following patch.
MTU set to 4168 (4096 TCP payload, 40 bytes IPv6 header, 32 bytes TCP header)
Without mmap() (tcp_mmap -s)
received 32768 MB (0 % mmap'ed) in 8.13342 s, 33.7961 Gbit,
cpu usage user:0.034 sys:3.778, 116.333 usec per MB, 63062 c-switches
received 32768 MB (0 % mmap'ed) in 8.14501 s, 33.748 Gbit,
cpu usage user:0.029 sys:3.997, 122.864 usec per MB, 61903 c-switches
received 32768 MB (0 % mmap'ed) in 8.11723 s, 33.8635 Gbit,
cpu usage user:0.048 sys:3.964, 122.437 usec per MB, 62983 c-switches
received 32768 MB (0 % mmap'ed) in 8.39189 s, 32.7552 Gbit,
cpu usage user:0.038 sys:4.181, 128.754 usec per MB, 55834 c-switches
With mmap() on receiver (tcp_mmap -s -z)
received 32768 MB (100 % mmap'ed) in 8.03083 s, 34.2278 Gbit,
cpu usage user:0.024 sys:1.466, 45.4712 usec per MB, 65479 c-switches
received 32768 MB (100 % mmap'ed) in 7.98805 s, 34.4111 Gbit,
cpu usage user:0.026 sys:1.401, 43.5486 usec per MB, 65447 c-switches
received 32768 MB (100 % mmap'ed) in 7.98377 s, 34.4296 Gbit,
cpu usage user:0.028 sys:1.452, 45.166 usec per MB, 65496 c-switches
received 32768 MB (99.9969 % mmap'ed) in 8.01838 s, 34.281 Gbit,
cpu usage user:0.02 sys:1.446, 44.7388 usec per MB, 65505 c-switches
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-04-16 20:33:38 +03:00
int tcp_mmap ( struct file * file , struct socket * sock ,
struct vm_area_struct * vma ) ;
2019-01-17 13:03:14 +03:00
# endif
2017-06-07 20:34:36 +03:00
void tcp_parse_options ( const struct net * net , const struct sk_buff * skb ,
2013-09-23 22:33:32 +04:00
struct tcp_options_received * opt_rx ,
int estab , struct tcp_fastopen_cookie * foc ) ;
const u8 * tcp_parse_md5sig_option ( const struct tcphdr * th ) ;
2008-04-17 07:29:53 +04:00
2019-07-29 19:59:14 +03:00
/*
* BPF SKB - less helpers
*/
u16 tcp_v4_get_syncookie ( struct sock * sk , struct iphdr * iph ,
struct tcphdr * th , u32 * cookie ) ;
u16 tcp_v6_get_syncookie ( struct sock * sk , struct ipv6hdr * iph ,
struct tcphdr * th , u32 * cookie ) ;
u16 tcp_get_syncookie_mss ( struct request_sock_ops * rsk_ops ,
const struct tcp_request_sock_ops * af_ops ,
struct sock * sk , struct tcphdr * th ) ;
2005-04-17 02:20:36 +04:00
/*
* TCP v4 functions exported for the inet6 API
*/
2013-09-23 22:33:32 +04:00
void tcp_v4_send_check ( struct sock * sk , struct sk_buff * skb ) ;
2014-08-14 20:40:05 +04:00
void tcp_v4_mtu_reduced ( struct sock * sk ) ;
2016-02-03 06:31:12 +03:00
void tcp_req_err ( struct sock * sk , u32 seq , bool abort ) ;
2013-09-23 22:33:32 +04:00
int tcp_v4_conn_request ( struct sock * sk , struct sk_buff * skb ) ;
2015-09-29 17:42:47 +03:00
struct sock * tcp_create_openreq_child ( const struct sock * sk ,
2013-09-23 22:33:32 +04:00
struct request_sock * req ,
struct sk_buff * skb ) ;
net: tcp: add per route congestion control
This work adds the possibility to define a per route/destination
congestion control algorithm. Generally, this opens up the possibility
for a machine with different links to enforce specific congestion
control algorithms with optimal strategies for each of them based
on their network characteristics, even transparently for a single
application listening on all links.
For our specific use case, this additionally facilitates deployment
of DCTCP, for example, applications can easily serve internal
traffic/dsts in DCTCP and external one with CUBIC. Other scenarios
would also allow for utilizing e.g. long living, low priority
background flows for certain destinations/routes while still being
able for normal traffic to utilize the default congestion control
algorithm. We also thought about a per netns setting (where different
defaults are possible), but given its actually a link specific
property, we argue that a per route/destination setting is the most
natural and flexible.
The administrator can utilize this through ip-route(8) by appending
"congctl [lock] <name>", where <name> denotes the name of a
congestion control algorithm and the optional lock parameter allows
to enforce the given algorithm so that applications in user space
would not be allowed to overwrite that algorithm for that destination.
The dst metric lookups are being done when a dst entry is already
available in order to avoid a costly lookup and still before the
algorithms are being initialized, thus overhead is very low when the
feature is not being used. While the client side would need to drop
the current reference on the module, on server side this can actually
even be avoided as we just got a flat-copied socket clone.
Joint work with Florian Westphal.
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:48 +03:00
void tcp_ca_openreq_child ( struct sock * sk , const struct dst_entry * dst ) ;
2015-09-29 17:42:48 +03:00
struct sock * tcp_v4_syn_recv_sock ( const struct sock * sk , struct sk_buff * skb ,
2013-09-23 22:33:32 +04:00
struct request_sock * req ,
2015-10-22 18:20:46 +03:00
struct dst_entry * dst ,
struct request_sock * req_unhash ,
bool * own_req ) ;
2013-09-23 22:33:32 +04:00
int tcp_v4_do_rcv ( struct sock * sk , struct sk_buff * skb ) ;
int tcp_v4_connect ( struct sock * sk , struct sockaddr * uaddr , int addr_len ) ;
int tcp_connect ( struct sock * sk ) ;
2016-04-14 08:05:39 +03:00
enum tcp_synack_type {
TCP_SYNACK_NORMAL ,
TCP_SYNACK_FASTOPEN ,
TCP_SYNACK_COOKIE ,
} ;
2015-09-25 17:39:19 +03:00
struct sk_buff * tcp_make_synack ( const struct sock * sk , struct dst_entry * dst ,
2013-09-23 22:33:32 +04:00
struct request_sock * req ,
2015-10-02 21:43:35 +03:00
struct tcp_fastopen_cookie * foc ,
2016-04-14 08:05:39 +03:00
enum tcp_synack_type synack_type ) ;
2013-09-23 22:33:32 +04:00
int tcp_disconnect ( struct sock * sk , int flags ) ;
2005-04-17 02:20:36 +04:00
2012-04-19 07:40:01 +04:00
void tcp_finish_connect ( struct sock * sk , struct sk_buff * skb ) ;
2012-05-10 05:49:41 +04:00
int tcp_send_rcvq ( struct sock * sk , struct msghdr * msg , size_t size ) ;
2012-08-09 18:11:00 +04:00
void inet_sk_rx_dst_set ( struct sock * sk , const struct sk_buff * skb ) ;
2005-04-17 02:20:36 +04:00
/* From syncookies.c */
2015-06-05 04:30:43 +03:00
struct sock * tcp_get_cookie_sock ( struct sock * sk , struct sk_buff * skb ,
struct request_sock * req ,
2017-05-05 16:56:54 +03:00
struct dst_entry * dst , u32 tsoff ) ;
2013-09-23 22:33:32 +04:00
int __cookie_v4_check ( const struct iphdr * iph , const struct tcphdr * th ,
u32 cookie ) ;
2014-10-16 01:33:22 +04:00
struct sock * cookie_v4_check ( struct sock * sk , struct sk_buff * skb ) ;
2011-09-19 05:02:55 +04:00
# ifdef CONFIG_SYN_COOKIES
2013-09-21 00:32:55 +04:00
2014-03-20 08:02:21 +04:00
/* Syncookies use a monotonic timer which increments every 60 seconds.
2013-09-21 00:32:55 +04:00
* This counter is used both as a hash input and partially encoded into
* the cookie value . A cookie is only validated further if the delta
* between the current counter value and the encoded one is less than this ,
2014-03-20 08:02:21 +04:00
* i . e . a sent cookie is valid only at most for 2 * 60 seconds ( or less if
2013-09-21 00:32:55 +04:00
* the counter advances immediately after a cookie is generated ) .
*/
2015-05-15 00:26:56 +03:00
# define MAX_SYNCOOKIE_AGE 2
# define TCP_SYNCOOKIE_PERIOD (60 * HZ)
# define TCP_SYNCOOKIE_VALID (MAX_SYNCOOKIE_AGE * TCP_SYNCOOKIE_PERIOD)
/* syncookies: remember time of last synqueue overflow
* But do not dirty this field too often ( once per second is enough )
2015-09-29 17:42:49 +03:00
* It is racy as we do not hold a lock , but race is very minor .
2015-05-15 00:26:56 +03:00
*/
2015-09-29 17:42:49 +03:00
static inline void tcp_synq_overflow ( const struct sock * sk )
2015-05-15 00:26:56 +03:00
{
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
unsigned int last_overflow ;
2018-07-11 13:16:12 +03:00
unsigned int now = jiffies ;
2015-05-15 00:26:56 +03:00
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
if ( sk - > sk_reuseport ) {
struct sock_reuseport * reuse ;
reuse = rcu_dereference ( sk - > sk_reuseport_cb ) ;
if ( likely ( reuse ) ) {
last_overflow = READ_ONCE ( reuse - > synq_overflow_ts ) ;
tcp: fix rejected syncookies due to stale timestamps
If no synflood happens for a long enough period of time, then the
synflood timestamp isn't refreshed and jiffies can advance so much
that time_after32() can't accurately compare them any more.
Therefore, we can end up in a situation where time_after32(now,
last_overflow + HZ) returns false, just because these two values are
too far apart. In that case, the synflood timestamp isn't updated as
it should be, which can trick tcp_synq_no_recent_overflow() into
rejecting valid syncookies.
For example, let's consider the following scenario on a system
with HZ=1000:
* The synflood timestamp is 0, either because that's the timestamp
of the last synflood or, more commonly, because we're working with
a freshly created socket.
* We receive a new SYN, which triggers synflood protection. Let's say
that this happens when jiffies == 2147484649 (that is,
'synflood timestamp' + HZ + 2^31 + 1).
* Then tcp_synq_overflow() doesn't update the synflood timestamp,
because time_after32(2147484649, 1000) returns false.
With:
- 2147484649: the value of jiffies, aka. 'now'.
- 1000: the value of 'last_overflow' + HZ.
* A bit later, we receive the ACK completing the 3WHS. But
cookie_v[46]_check() rejects it because tcp_synq_no_recent_overflow()
says that we're not under synflood. That's because
time_after32(2147484649, 120000) returns false.
With:
- 2147484649: the value of jiffies, aka. 'now'.
- 120000: the value of 'last_overflow' + TCP_SYNCOOKIE_VALID.
Of course, in reality jiffies would have increased a bit, but this
condition will last for the next 119 seconds, which is far enough
to accommodate for jiffie's growth.
Fix this by updating the overflow timestamp whenever jiffies isn't
within the [last_overflow, last_overflow + HZ] range. That shouldn't
have any performance impact since the update still happens at most once
per second.
Now we're guaranteed to have fresh timestamps while under synflood, so
tcp_synq_no_recent_overflow() can safely use it with time_after32() in
such situations.
Stale timestamps can still make tcp_synq_no_recent_overflow() return
the wrong verdict when not under synflood. This will be handled in the
next patch.
For 64 bits architectures, the problem was introduced with the
conversion of ->tw_ts_recent_stamp to 32 bits integer by commit
cca9bab1b72c ("tcp: use monotonic timestamps for PAWS").
The problem has always been there on 32 bits architectures.
Fixes: cca9bab1b72c ("tcp: use monotonic timestamps for PAWS")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-06 14:38:36 +03:00
if ( ! time_between32 ( now , last_overflow ,
last_overflow + HZ ) )
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
WRITE_ONCE ( reuse - > synq_overflow_ts , now ) ;
return ;
}
}
2019-12-06 14:38:49 +03:00
last_overflow = READ_ONCE ( tcp_sk ( sk ) - > rx_opt . ts_recent_stamp ) ;
tcp: fix rejected syncookies due to stale timestamps
If no synflood happens for a long enough period of time, then the
synflood timestamp isn't refreshed and jiffies can advance so much
that time_after32() can't accurately compare them any more.
Therefore, we can end up in a situation where time_after32(now,
last_overflow + HZ) returns false, just because these two values are
too far apart. In that case, the synflood timestamp isn't updated as
it should be, which can trick tcp_synq_no_recent_overflow() into
rejecting valid syncookies.
For example, let's consider the following scenario on a system
with HZ=1000:
* The synflood timestamp is 0, either because that's the timestamp
of the last synflood or, more commonly, because we're working with
a freshly created socket.
* We receive a new SYN, which triggers synflood protection. Let's say
that this happens when jiffies == 2147484649 (that is,
'synflood timestamp' + HZ + 2^31 + 1).
* Then tcp_synq_overflow() doesn't update the synflood timestamp,
because time_after32(2147484649, 1000) returns false.
With:
- 2147484649: the value of jiffies, aka. 'now'.
- 1000: the value of 'last_overflow' + HZ.
* A bit later, we receive the ACK completing the 3WHS. But
cookie_v[46]_check() rejects it because tcp_synq_no_recent_overflow()
says that we're not under synflood. That's because
time_after32(2147484649, 120000) returns false.
With:
- 2147484649: the value of jiffies, aka. 'now'.
- 120000: the value of 'last_overflow' + TCP_SYNCOOKIE_VALID.
Of course, in reality jiffies would have increased a bit, but this
condition will last for the next 119 seconds, which is far enough
to accommodate for jiffie's growth.
Fix this by updating the overflow timestamp whenever jiffies isn't
within the [last_overflow, last_overflow + HZ] range. That shouldn't
have any performance impact since the update still happens at most once
per second.
Now we're guaranteed to have fresh timestamps while under synflood, so
tcp_synq_no_recent_overflow() can safely use it with time_after32() in
such situations.
Stale timestamps can still make tcp_synq_no_recent_overflow() return
the wrong verdict when not under synflood. This will be handled in the
next patch.
For 64 bits architectures, the problem was introduced with the
conversion of ->tw_ts_recent_stamp to 32 bits integer by commit
cca9bab1b72c ("tcp: use monotonic timestamps for PAWS").
The problem has always been there on 32 bits architectures.
Fixes: cca9bab1b72c ("tcp: use monotonic timestamps for PAWS")
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-06 14:38:36 +03:00
if ( ! time_between32 ( now , last_overflow , last_overflow + HZ ) )
2019-12-06 14:38:49 +03:00
WRITE_ONCE ( tcp_sk ( sk ) - > rx_opt . ts_recent_stamp , now ) ;
2015-05-15 00:26:56 +03:00
}
/* syncookies: no recent synqueue overflow on this listening socket? */
static inline bool tcp_synq_no_recent_overflow ( const struct sock * sk )
{
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
unsigned int last_overflow ;
2018-07-11 13:16:12 +03:00
unsigned int now = jiffies ;
2015-05-15 00:26:56 +03:00
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
if ( sk - > sk_reuseport ) {
struct sock_reuseport * reuse ;
reuse = rcu_dereference ( sk - > sk_reuseport_cb ) ;
if ( likely ( reuse ) ) {
last_overflow = READ_ONCE ( reuse - > synq_overflow_ts ) ;
tcp: tighten acceptance of ACKs not matching a child socket
When no synflood occurs, the synflood timestamp isn't updated.
Therefore it can be so old that time_after32() can consider it to be
in the future.
That's a problem for tcp_synq_no_recent_overflow() as it may report
that a recent overflow occurred while, in fact, it's just that jiffies
has grown past 'last_overflow' + TCP_SYNCOOKIE_VALID + 2^31.
Spurious detection of recent overflows lead to extra syncookie
verification in cookie_v[46]_check(). At that point, the verification
should fail and the packet dropped. But we should have dropped the
packet earlier as we didn't even send a syncookie.
Let's refine tcp_synq_no_recent_overflow() to report a recent overflow
only if jiffies is within the
[last_overflow, last_overflow + TCP_SYNCOOKIE_VALID] interval. This
way, no spurious recent overflow is reported when jiffies wraps and
'last_overflow' becomes in the future from the point of view of
time_after32().
However, if jiffies wraps and enters the
[last_overflow, last_overflow + TCP_SYNCOOKIE_VALID] interval (with
'last_overflow' being a stale synflood timestamp), then
tcp_synq_no_recent_overflow() still erroneously reports an
overflow. In such cases, we have to rely on syncookie verification
to drop the packet. We unfortunately have no way to differentiate
between a fresh and a stale syncookie timestamp.
In practice, using last_overflow as lower bound is problematic.
If the synflood timestamp is concurrently updated between the time
we read jiffies and the moment we store the timestamp in
'last_overflow', then 'now' becomes smaller than 'last_overflow' and
tcp_synq_no_recent_overflow() returns true, potentially dropping a
valid syncookie.
Reading jiffies after loading the timestamp could fix the problem,
but that'd require a memory barrier. Let's just accommodate for
potential timestamp growth instead and extend the interval using
'last_overflow - HZ' as lower bound.
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-06 14:38:43 +03:00
return ! time_between32 ( now , last_overflow - HZ ,
last_overflow +
TCP_SYNCOOKIE_VALID ) ;
tcp: Avoid TCP syncookie rejected by SO_REUSEPORT socket
Although the actual cookie check "__cookie_v[46]_check()" does
not involve sk specific info, it checks whether the sk has recent
synq overflow event in "tcp_synq_no_recent_overflow()". The
tcp_sk(sk)->rx_opt.ts_recent_stamp is updated every second
when it has sent out a syncookie (through "tcp_synq_overflow()").
The above per sk "recent synq overflow event timestamp" works well
for non SO_REUSEPORT use case. However, it may cause random
connection request reject/discard when SO_REUSEPORT is used with
syncookie because it fails the "tcp_synq_no_recent_overflow()"
test.
When SO_REUSEPORT is used, it usually has multiple listening
socks serving TCP connection requests destinated to the same local IP:PORT.
There are cases that the TCP-ACK-COOKIE may not be received
by the same sk that sent out the syncookie. For example,
if reuse->socks[] began with {sk0, sk1},
1) sk1 sent out syncookies and tcp_sk(sk1)->rx_opt.ts_recent_stamp
was updated.
2) the reuse->socks[] became {sk1, sk2} later. e.g. sk0 was first closed
and then sk2 was added. Here, sk2 does not have ts_recent_stamp set.
There are other ordering that will trigger the similar situation
below but the idea is the same.
3) When the TCP-ACK-COOKIE comes back, sk2 was selected.
"tcp_synq_no_recent_overflow(sk2)" returns true. In this case,
all syncookies sent by sk1 will be handled (and rejected)
by sk2 while sk1 is still alive.
The userspace may create and remove listening SO_REUSEPORT sockets
as it sees fit. E.g. Adding new thread (and SO_REUSEPORT sock) to handle
incoming requests, old process stopping and new process starting...etc.
With or without SO_ATTACH_REUSEPORT_[CB]BPF,
the sockets leaving and joining a reuseport group makes picking
the same sk to check the syncookie very difficult (if not impossible).
The later patches will allow bpf prog more flexibility in deciding
where a sk should be located in a bpf map and selecting a particular
SO_REUSEPORT sock as it sees fit. e.g. Without closing any sock,
replace the whole bpf reuseport_array in one map_update() by using
map-in-map. Getting the syncookie check working smoothly across
socks in the same "reuse->socks[]" is important.
A partial solution is to set the newly added sk's ts_recent_stamp
to the max ts_recent_stamp of a reuseport group but that will require
to iterate through reuse->socks[] OR
pessimistically set it to "now - TCP_SYNCOOKIE_VALID" when a sk is
joining a reuseport group. However, neither of them will solve the
existing sk getting moved around the reuse->socks[] and that
sk may not have ts_recent_stamp updated, unlikely under continuous
synflood but not impossible.
This patch opts to treat the reuseport group as a whole when
considering the last synq overflow timestamp since
they are serving the same IP:PORT from the userspace
(and BPF program) perspective.
"synq_overflow_ts" is added to "struct sock_reuseport".
The tcp_synq_overflow() and tcp_synq_no_recent_overflow()
will update/check reuse->synq_overflow_ts if the sk is
in a reuseport group. Similar to the reuseport decision in
__inet_lookup_listener(), both sk->sk_reuseport and
sk->sk_reuseport_cb are tested for SO_REUSEPORT usage.
Update on "synq_overflow_ts" happens at roughly once
every second.
A synflood test was done with a 16 rx-queues and 16 reuseport sockets.
No meaningful performance change is observed. Before and
after the change is ~9Mpps in IPv4.
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2018-08-08 11:01:21 +03:00
}
}
2019-12-06 14:38:49 +03:00
last_overflow = READ_ONCE ( tcp_sk ( sk ) - > rx_opt . ts_recent_stamp ) ;
tcp: tighten acceptance of ACKs not matching a child socket
When no synflood occurs, the synflood timestamp isn't updated.
Therefore it can be so old that time_after32() can consider it to be
in the future.
That's a problem for tcp_synq_no_recent_overflow() as it may report
that a recent overflow occurred while, in fact, it's just that jiffies
has grown past 'last_overflow' + TCP_SYNCOOKIE_VALID + 2^31.
Spurious detection of recent overflows lead to extra syncookie
verification in cookie_v[46]_check(). At that point, the verification
should fail and the packet dropped. But we should have dropped the
packet earlier as we didn't even send a syncookie.
Let's refine tcp_synq_no_recent_overflow() to report a recent overflow
only if jiffies is within the
[last_overflow, last_overflow + TCP_SYNCOOKIE_VALID] interval. This
way, no spurious recent overflow is reported when jiffies wraps and
'last_overflow' becomes in the future from the point of view of
time_after32().
However, if jiffies wraps and enters the
[last_overflow, last_overflow + TCP_SYNCOOKIE_VALID] interval (with
'last_overflow' being a stale synflood timestamp), then
tcp_synq_no_recent_overflow() still erroneously reports an
overflow. In such cases, we have to rely on syncookie verification
to drop the packet. We unfortunately have no way to differentiate
between a fresh and a stale syncookie timestamp.
In practice, using last_overflow as lower bound is problematic.
If the synflood timestamp is concurrently updated between the time
we read jiffies and the moment we store the timestamp in
'last_overflow', then 'now' becomes smaller than 'last_overflow' and
tcp_synq_no_recent_overflow() returns true, potentially dropping a
valid syncookie.
Reading jiffies after loading the timestamp could fix the problem,
but that'd require a memory barrier. Let's just accommodate for
potential timestamp growth instead and extend the interval using
'last_overflow - HZ' as lower bound.
Signed-off-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-06 14:38:43 +03:00
/* If last_overflow <= jiffies <= last_overflow + TCP_SYNCOOKIE_VALID,
* then we ' re under synflood . However , we have to use
* ' last_overflow - HZ ' as lower bound . That ' s because a concurrent
* tcp_synq_overflow ( ) could update . ts_recent_stamp after we read
* jiffies but before we store . ts_recent_stamp into last_overflow ,
* which could lead to rejecting a valid syncookie .
*/
return ! time_between32 ( now , last_overflow - HZ ,
last_overflow + TCP_SYNCOOKIE_VALID ) ;
2015-05-15 00:26:56 +03:00
}
2013-09-21 00:32:55 +04:00
static inline u32 tcp_cookie_time ( void )
{
2014-03-20 08:02:21 +04:00
u64 val = get_jiffies_64 ( ) ;
2015-05-15 00:26:56 +03:00
do_div ( val , TCP_SYNCOOKIE_PERIOD ) ;
2014-03-20 08:02:21 +04:00
return val ;
2013-09-21 00:32:55 +04:00
}
2013-09-23 22:33:32 +04:00
u32 __cookie_v4_init_sequence ( const struct iphdr * iph , const struct tcphdr * th ,
u16 * mssp ) ;
2015-09-29 17:42:49 +03:00
__u32 cookie_v4_init_sequence ( const struct sk_buff * skb , __u16 * mss ) ;
2019-11-07 22:51:18 +03:00
u64 cookie_init_timestamp ( struct request_sock * req , u64 now ) ;
2017-06-07 20:34:37 +03:00
bool cookie_timestamp_decode ( const struct net * net ,
struct tcp_options_received * opt ) ;
syncookies: split cookie_check_timestamp() into two functions
The function cookie_check_timestamp(), both called from IPv4/6 context,
is being used to decode the echoed timestamp from the SYN/ACK into TCP
options used for follow-up communication with the peer.
We can remove ECN handling from that function, split it into a separate
one, and simply rename the original function into cookie_decode_options().
cookie_decode_options() just fills in tcp_option struct based on the
echoed timestamp received from the peer. Anything that fails in this
function will actually discard the request socket.
While this is the natural place for decoding options such as ECN which
commit 172d69e63c7f ("syncookies: add support for ECN") added, we argue
that in particular for ECN handling, it can be checked at a later point
in time as the request sock would actually not need to be dropped from
this, but just ECN support turned off.
Therefore, we split this functionality into cookie_ecn_ok(), which tells
us if the timestamp indicates ECN support AND the tcp_ecn sysctl is enabled.
This prepares for per-route ECN support: just looking at the tcp_ecn sysctl
won't be enough anymore at that point; if the timestamp indicates ECN
and sysctl tcp_ecn == 0, we will also need to check the ECN dst metric.
This would mean adding a route lookup to cookie_check_timestamp(), which
we definitely want to avoid. As we already do a route lookup at a later
point in cookie_{v4,v6}_check(), we can simply make use of that as well
for the new cookie_ecn_ok() function w/o any additional cost.
Joint work with Daniel Borkmann.
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-03 19:35:02 +03:00
bool cookie_ecn_ok ( const struct tcp_options_received * opt ,
net: allow setting ecn via routing table
This patch allows to set ECN on a per-route basis in case the sysctl
tcp_ecn is not set to 1. In other words, when ECN is set for specific
routes, it provides a tcp_ecn=1 behaviour for that route while the rest
of the stack acts according to the global settings.
One can use 'ip route change dev $dev $net features ecn' to toggle this.
Having a more fine-grained per-route setting can be beneficial for various
reasons, for example, 1) within data centers, or 2) local ISPs may deploy
ECN support for their own video/streaming services [1], etc.
There was a recent measurement study/paper [2] which scanned the Alexa's
publicly available top million websites list from a vantage point in US,
Europe and Asia:
Half of the Alexa list will now happily use ECN (tcp_ecn=2, most likely
blamed to commit 255cac91c3 ("tcp: extend ECN sysctl to allow server-side
only ECN") ;)); the break in connectivity on-path was found is about
1 in 10,000 cases. Timeouts rather than receiving back RSTs were much
more common in the negotiation phase (and mostly seen in the Alexa
middle band, ranks around 50k-150k): from 12-thousand hosts on which
there _may_ be ECN-linked connection failures, only 79 failed with RST
when _not_ failing with RST when ECN is not requested.
It's unclear though, how much equipment in the wild actually marks CE
when buffers start to fill up.
We thought about a fallback to non-ECN for retransmitted SYNs as another
global option (which could perhaps one day be made default), but as Eric
points out, there's much more work needed to detect broken middleboxes.
Two examples Eric mentioned are buggy firewalls that accept only a single
SYN per flow, and middleboxes that successfully let an ECN flow establish,
but later mark CE for all packets (so cwnd converges to 1).
[1] http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf, p.15
[2] http://ecn.ethz.ch/
Joint work with Daniel Borkmann.
Reference: http://thread.gmane.org/gmane.linux.network/335797
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-03 19:35:03 +03:00
const struct net * net , const struct dst_entry * dst ) ;
2008-04-10 14:12:40 +04:00
2008-02-08 08:49:26 +03:00
/* From net/ipv6/syncookies.c */
2013-09-23 22:33:32 +04:00
int __cookie_v6_check ( const struct ipv6hdr * iph , const struct tcphdr * th ,
u32 cookie ) ;
struct sock * cookie_v6_check ( struct sock * sk , struct sk_buff * skb ) ;
syncookies: split cookie_check_timestamp() into two functions
The function cookie_check_timestamp(), both called from IPv4/6 context,
is being used to decode the echoed timestamp from the SYN/ACK into TCP
options used for follow-up communication with the peer.
We can remove ECN handling from that function, split it into a separate
one, and simply rename the original function into cookie_decode_options().
cookie_decode_options() just fills in tcp_option struct based on the
echoed timestamp received from the peer. Anything that fails in this
function will actually discard the request socket.
While this is the natural place for decoding options such as ECN which
commit 172d69e63c7f ("syncookies: add support for ECN") added, we argue
that in particular for ECN handling, it can be checked at a later point
in time as the request sock would actually not need to be dropped from
this, but just ECN support turned off.
Therefore, we split this functionality into cookie_ecn_ok(), which tells
us if the timestamp indicates ECN support AND the tcp_ecn sysctl is enabled.
This prepares for per-route ECN support: just looking at the tcp_ecn sysctl
won't be enough anymore at that point; if the timestamp indicates ECN
and sysctl tcp_ecn == 0, we will also need to check the ECN dst metric.
This would mean adding a route lookup to cookie_check_timestamp(), which
we definitely want to avoid. As we already do a route lookup at a later
point in cookie_{v4,v6}_check(), we can simply make use of that as well
for the new cookie_ecn_ok() function w/o any additional cost.
Joint work with Daniel Borkmann.
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-03 19:35:02 +03:00
2013-09-23 22:33:32 +04:00
u32 __cookie_v6_init_sequence ( const struct ipv6hdr * iph ,
const struct tcphdr * th , u16 * mssp ) ;
2015-09-29 17:42:49 +03:00
__u32 cookie_v6_init_sequence ( const struct sk_buff * skb , __u16 * mss ) ;
2011-09-19 05:02:55 +04:00
# endif
2005-04-17 02:20:36 +04:00
/* tcp_output.c */
2013-09-23 22:33:32 +04:00
void __tcp_push_pending_frames ( struct sock * sk , unsigned int cur_mss ,
int nonagle ) ;
tcp-tso: do not split TSO packets at retransmit time
Linux TCP stack painfully segments all TSO/GSO packets before retransmits.
This was fine back in the days when TSO/GSO were emerging, with their
bugs, but we believe the dark age is over.
Keeping big packets in write queues, but also in stack traversal
has a lot of benefits.
- Less memory overhead, because write queues have less skbs
- Less cpu overhead at ACK processing.
- Better SACK processing, as lot of studies mentioned how
awful linux was at this ;)
- Less cpu overhead to send the rtx packets
(IP stack traversal, netfilter traversal, drivers...)
- Better latencies in presence of losses.
- Smaller spikes in fq like packet schedulers, as retransmits
are not constrained by TCP Small Queues.
1 % packet losses are common today, and at 100Gbit speeds, this
translates to ~80,000 losses per second.
Losses are often correlated, and we see many retransmit events
leading to 1-MSS train of packets, at the time hosts are already
under stress.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-21 20:55:23 +03:00
int __tcp_retransmit_skb ( struct sock * sk , struct sk_buff * skb , int segs ) ;
int tcp_retransmit_skb ( struct sock * sk , struct sk_buff * skb , int segs ) ;
2013-09-23 22:33:32 +04:00
void tcp_retransmit_timer ( struct sock * sk ) ;
void tcp_xmit_retransmit_queue ( struct sock * ) ;
void tcp_simple_retransmit ( struct sock * ) ;
2017-01-13 09:11:33 +03:00
void tcp_enter_recovery ( struct sock * sk , bool ece_ack ) ;
2013-09-23 22:33:32 +04:00
int tcp_trim_head ( struct sock * , struct sk_buff * , u32 ) ;
2017-10-06 08:21:27 +03:00
enum tcp_queue {
TCP_FRAG_IN_WRITE_QUEUE ,
TCP_FRAG_IN_RTX_QUEUE ,
} ;
int tcp_fragment ( struct sock * sk , enum tcp_queue tcp_queue ,
struct sk_buff * skb , u32 len ,
unsigned int mss_now , gfp_t gfp ) ;
2013-09-23 22:33:32 +04:00
void tcp_send_probe0 ( struct sock * ) ;
void tcp_send_partial ( struct sock * ) ;
2015-05-07 00:26:25 +03:00
int tcp_write_wakeup ( struct sock * , int mib ) ;
2013-09-23 22:33:32 +04:00
void tcp_send_fin ( struct sock * sk ) ;
void tcp_send_active_reset ( struct sock * sk , gfp_t priority ) ;
int tcp_send_synack ( struct sock * ) ;
void tcp_push_one ( struct sock * , unsigned int mss_now ) ;
2018-07-18 23:56:35 +03:00
void __tcp_send_ack ( struct sock * sk , u32 rcv_nxt ) ;
2013-09-23 22:33:32 +04:00
void tcp_send_ack ( struct sock * sk ) ;
void tcp_send_delayed_ack ( struct sock * sk ) ;
void tcp_send_loss_probe ( struct sock * sk ) ;
tcp: when scheduling TLP, time of RTO should account for current ACK
Fix the TLP scheduling logic so that when scheduling a TLP probe, we
ensure that the estimated time at which an RTO would fire accounts for
the fact that ACKs indicating forward progress should push back RTO
times.
After the following fix:
df92c8394e6e ("tcp: fix xmit timer to only be reset if data ACKed/SACKed")
we had an unintentional behavior change in the following kind of
scenario: suppose the RTT variance has been very low recently. Then
suppose we send out a flight of N packets and our RTT is 100ms:
t=0: send a flight of N packets
t=100ms: receive an ACK for N-1 packets
The response before df92c8394e6e that was:
-> schedule a TLP for now + RTO_interval
The response after df92c8394e6e is:
-> schedule a TLP for t=0 + RTO_interval
Since RTO_interval = srtt + RTT_variance, this means that we have
scheduled a TLP timer at a point in the future that only accounts for
RTT_variance. If the RTT_variance term is small, this means that the
timer fires soon.
Before df92c8394e6e this would not happen, because in that code, when
we receive an ACK for a prefix of flight, we did:
1) Near the top of tcp_ack(), switch from TLP timer to RTO
at write_queue_head->paket_tx_time + RTO_interval:
if (icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)
tcp_rearm_rto(sk);
2) In tcp_clean_rtx_queue(), update the RTO to now + RTO_interval:
if (flag & FLAG_ACKED) {
tcp_rearm_rto(sk);
3) In tcp_ack() after tcp_fastretrans_alert() switch from RTO
to TLP at now + RTO_interval:
if (icsk->icsk_pending == ICSK_TIME_RETRANS)
tcp_schedule_loss_probe(sk);
In df92c8394e6e we removed that 3-phase dance, and instead directly
set the TLP timer once: we set the TLP timer in cases like this to
write_queue_head->packet_tx_time + RTO_interval. So if the RTT
variance is small, then this means that this is setting the TLP timer
to fire quite soon. This means if the ACK for the tail of the flight
takes longer than an RTT to arrive (often due to delayed ACKs), then
the TLP timer fires too quickly.
Fixes: df92c8394e6e ("tcp: fix xmit timer to only be reset if data ACKed/SACKed")
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-18 05:06:14 +03:00
bool tcp_schedule_loss_probe ( struct sock * sk , bool advancing_rto ) ;
tcp: Merge tx_flags and tskey in tcp_shifted_skb
After receiving sacks, tcp_shifted_skb() will collapse
skbs if possible. tx_flags and tskey also have to be
merged.
This patch reuses the tcp_skb_collapse_tstamp() to handle
them.
BPF Output Before:
~~~~~
<no-output-due-to-missing-tstamp-event>
BPF Output After:
~~~~~
<...>-2024 [007] d.s. 88.644374: : ee_data:14599
Packetdrill Script:
~~~~~
+0 `sysctl -q -w net.ipv4.tcp_min_tso_segs=10`
+0 `sysctl -q -w net.ipv4.tcp_no_metrics_save=1`
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
0.100 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
0.100 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
0.200 write(4, ..., 1460) = 1460
+0 setsockopt(4, SOL_SOCKET, 37, [2688], 4) = 0
0.200 write(4, ..., 13140) = 13140
0.200 > P. 1:1461(1460) ack 1
0.200 > . 1461:8761(7300) ack 1
0.200 > P. 8761:14601(5840) ack 1
0.300 < . 1:1(0) ack 1 win 257 <sack 1461:14601,nop,nop>
0.300 > P. 1:1461(1460) ack 1
0.400 < . 1:1(0) ack 14601 win 257
0.400 close(4) = 0
0.400 > F. 14601:14601(0) ack 1
0.500 < F. 1:1(0) ack 14602 win 257
0.500 > . 14602:14602(0) ack 2
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Tested-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-20 08:39:29 +03:00
void tcp_skb_collapse_tstamp ( struct sk_buff * skb ,
const struct sk_buff * next_skb ) ;
2005-04-17 02:20:36 +04:00
2005-07-06 02:18:51 +04:00
/* tcp_input.c */
2013-09-23 22:33:32 +04:00
void tcp_rearm_rto ( struct sock * sk ) ;
2015-09-18 21:36:14 +03:00
void tcp_synack_rtt_meas ( struct sock * sk , struct request_sock * req ) ;
2013-09-23 22:33:32 +04:00
void tcp_reset ( struct sock * sk ) ;
2015-10-17 07:57:47 +03:00
void tcp_skb_mark_lost_uncond_verify ( struct tcp_sock * tp , struct sk_buff * skb ) ;
2016-02-06 22:16:28 +03:00
void tcp_fin ( struct sock * sk ) ;
2005-07-06 02:18:51 +04:00
2005-04-17 02:20:36 +04:00
/* tcp_timer.c */
2013-09-23 22:33:32 +04:00
void tcp_init_xmit_timers ( struct sock * ) ;
2005-08-10 07:10:42 +04:00
static inline void tcp_clear_xmit_timers ( struct sock * sk )
{
2018-05-11 00:59:43 +03:00
if ( hrtimer_try_to_cancel ( & tcp_sk ( sk ) - > pacing_timer ) = = 1 )
2018-05-18 00:47:24 +03:00
__sock_put ( sk ) ;
2018-05-11 00:59:43 +03:00
tcp: add SACK compression
When TCP receives an out-of-order packet, it immediately sends
a SACK packet, generating network load but also forcing the
receiver to send 1-MSS pathological packets, increasing its
RTX queue length/depth, and thus processing time.
Wifi networks suffer from this aggressive behavior, but generally
speaking, all these SACK packets add fuel to the fire when networks
are under congestion.
This patch adds a high resolution timer and tp->compressed_ack counter.
Instead of sending a SACK, we program this timer with a small delay,
based on RTT and capped to 1 ms :
delay = min ( 5 % of RTT, 1 ms)
If subsequent SACKs need to be sent while the timer has not yet
expired, we simply increment tp->compressed_ack.
When timer expires, a SACK is sent with the latest information.
Whenever an ACK is sent (if data is sent, or if in-order
data is received) timer is canceled.
Note that tcp_sack_new_ofo_skb() is able to force a SACK to be sent
if the sack blocks need to be shuffled, even if the timer has not
expired.
A new SNMP counter is added in the following patch.
Two other patches add sysctls to allow changing the 1,000,000 and 44
values that this commit hard-coded.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-18 00:47:26 +03:00
if ( hrtimer_try_to_cancel ( & tcp_sk ( sk ) - > compressed_ack_timer ) = = 1 )
__sock_put ( sk ) ;
2005-08-10 07:10:42 +04:00
inet_csk_clear_xmit_timers ( sk ) ;
}
2005-04-17 02:20:36 +04:00
2013-09-23 22:33:32 +04:00
unsigned int tcp_sync_mss ( struct sock * sk , u32 pmtu ) ;
unsigned int tcp_current_mss ( struct sock * sk ) ;
2009-03-14 17:23:05 +03:00
/* Bound MSS / TSO packet size with the half of the window */
static inline int tcp_bound_to_half_wnd ( struct tcp_sock * tp , int pktsize )
{
2010-09-15 21:27:52 +04:00
int cutoff ;
/* When peer uses tiny windows, there is no use in packetizing
* to sub - MSS pieces for the sake of SWS or making sure there
* are enough packets in the pipe for fast recovery .
*
* On the other hand , for extremely large MSS devices , handling
* smaller than MSS windows in this way does make sense .
*/
2016-06-29 02:06:48 +03:00
if ( tp - > max_window > TCP_MSS_DEFAULT )
2010-09-15 21:27:52 +04:00
cutoff = ( tp - > max_window > > 1 ) ;
else
cutoff = tp - > max_window ;
if ( cutoff & & pktsize > cutoff )
return max_t ( int , cutoff , 68U - tp - > tcp_header_len ) ;
2009-03-14 17:23:05 +03:00
else
return pktsize ;
}
2005-04-17 02:20:36 +04:00
[INET_DIAG]: Move the tcp_diag interface to the proper place
With this the previous setup is back, i.e. tcp_diag can be built as a module,
as dccp_diag and both share the infrastructure available in inet_diag.
If one selects CONFIG_INET_DIAG as module CONFIG_INET_TCP_DIAG will also be
built as a module, as will CONFIG_INET_DCCP_DIAG, if CONFIG_IP_DCCP was
selected static or as a module, if CONFIG_INET_DIAG is y, being statically
linked CONFIG_INET_TCP_DIAG will follow suit and CONFIG_INET_DCCP_DIAG will be
built in the same manner as CONFIG_IP_DCCP.
Now to aim at UDP, converting it to use inet_hashinfo, so that we can use
iproute2 for UDP sockets as well.
Ah, just to show an example of this new infrastructure working for DCCP :-)
[root@qemu ~]# ./ss -dane
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 *:5001 *:* ino:942 sk:cfd503a0
ESTAB 0 0 127.0.0.1:5001 127.0.0.1:32770 ino:943 sk:cfd50a60
ESTAB 0 0 127.0.0.1:32770 127.0.0.1:5001 ino:947 sk:cfd50700
TIME-WAIT 0 0 127.0.0.1:32769 127.0.0.1:5001 timer:(timewait,3.430ms,0) ino:0 sk:cf209620
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-12 19:59:17 +04:00
/* tcp.c */
2015-04-29 01:28:17 +03:00
void tcp_get_info ( struct sock * , struct tcp_info * ) ;
2005-04-17 02:20:36 +04:00
/* Read 'sendfile()'-style from a TCP socket */
2013-09-23 22:33:32 +04:00
int tcp_read_sock ( struct sock * sk , read_descriptor_t * desc ,
sk_read_actor_t recv_actor ) ;
2005-04-17 02:20:36 +04:00
2013-09-23 22:33:32 +04:00
void tcp_initialize_rcv_mss ( struct sock * sk ) ;
2005-04-17 02:20:36 +04:00
2013-09-23 22:33:32 +04:00
int tcp_mtu_to_mss ( struct sock * sk , int pmtu ) ;
int tcp_mss_to_mtu ( struct sock * sk , int mss ) ;
void tcp_mtup_init ( struct sock * sk ) ;
void tcp_init_buffer_space ( struct sock * sk ) ;
2006-03-21 04:53:41 +03:00
Revert Backoff [v3]: Revert RTO on ICMP destination unreachable
Here, an ICMP host/network unreachable message, whose payload fits to
TCP's SND.UNA, is taken as an indication that the RTO retransmission has
not been lost due to congestion, but because of a route failure
somewhere along the path.
With true congestion, a router won't trigger such a message and the
patched TCP will operate as standard TCP.
This patch reverts one RTO backoff, if an ICMP host/network unreachable
message, whose payload fits to TCP's SND.UNA, arrives.
Based on the new RTO, the retransmission timer is reset to reflect the
remaining time, or - if the revert clocked out the timer - a retransmission
is sent out immediately.
Backoffs are only reverted, if TCP is in RTO loss recovery, i.e. if
there have been retransmissions and reversible backoffs, already.
Changes from v2:
1) Renaming of skb in tcp_v4_err() moved to another patch.
2) Reintroduced tcp_bound_rto() and __tcp_set_rto().
3) Fixed code comments.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-26 04:16:31 +04:00
static inline void tcp_bound_rto ( const struct sock * sk )
{
if ( inet_csk ( sk ) - > icsk_rto > TCP_RTO_MAX )
inet_csk ( sk ) - > icsk_rto = TCP_RTO_MAX ;
}
static inline u32 __tcp_set_rto ( const struct tcp_sock * tp )
{
2014-02-27 02:02:48 +04:00
return usecs_to_jiffies ( ( tp - > srtt_us > > 3 ) + tp - > rttvar_us ) ;
Revert Backoff [v3]: Revert RTO on ICMP destination unreachable
Here, an ICMP host/network unreachable message, whose payload fits to
TCP's SND.UNA, is taken as an indication that the RTO retransmission has
not been lost due to congestion, but because of a route failure
somewhere along the path.
With true congestion, a router won't trigger such a message and the
patched TCP will operate as standard TCP.
This patch reverts one RTO backoff, if an ICMP host/network unreachable
message, whose payload fits to TCP's SND.UNA, arrives.
Based on the new RTO, the retransmission timer is reset to reflect the
remaining time, or - if the revert clocked out the timer - a retransmission
is sent out immediately.
Backoffs are only reverted, if TCP is in RTO loss recovery, i.e. if
there have been retransmissions and reversible backoffs, already.
Changes from v2:
1) Renaming of skb in tcp_v4_err() moved to another patch.
2) Reintroduced tcp_bound_rto() and __tcp_set_rto().
3) Fixed code comments.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-08-26 04:16:31 +04:00
}
2017-08-30 20:24:58 +03:00
static inline void __tcp_fast_path_on ( struct tcp_sock * tp , u32 snd_wnd )
{
tp - > pred_flags = htonl ( ( tp - > tcp_header_len < < 26 ) |
ntohl ( TCP_FLAG_ACK ) |
snd_wnd ) ;
}
static inline void tcp_fast_path_on ( struct tcp_sock * tp )
{
__tcp_fast_path_on ( tp , tp - > snd_wnd > > tp - > rx_opt . snd_wscale ) ;
}
static inline void tcp_fast_path_check ( struct sock * sk )
{
struct tcp_sock * tp = tcp_sk ( sk ) ;
if ( RB_EMPTY_ROOT ( & tp - > out_of_order_queue ) & &
tp - > rcv_wnd & &
atomic_read ( & sk - > sk_rmem_alloc ) < sk - > sk_rcvbuf & &
! tp - > urg_data )
tcp_fast_path_on ( tp ) ;
}
2009-05-04 22:11:01 +04:00
/* Compute the actual rto_min value */
static inline u32 tcp_rto_min ( struct sock * sk )
{
2011-10-21 13:22:42 +04:00
const struct dst_entry * dst = __sk_dst_get ( sk ) ;
2009-05-04 22:11:01 +04:00
u32 rto_min = TCP_RTO_MIN ;
if ( dst & & dst_metric_locked ( dst , RTAX_RTO_MIN ) )
rto_min = dst_metric_rtt ( dst , RTAX_RTO_MIN ) ;
return rto_min ;
}
2014-02-27 02:02:48 +04:00
static inline u32 tcp_rto_min_us ( struct sock * sk )
{
return jiffies_to_usecs ( tcp_rto_min ( sk ) ) ;
}
net: tcp: add per route congestion control
This work adds the possibility to define a per route/destination
congestion control algorithm. Generally, this opens up the possibility
for a machine with different links to enforce specific congestion
control algorithms with optimal strategies for each of them based
on their network characteristics, even transparently for a single
application listening on all links.
For our specific use case, this additionally facilitates deployment
of DCTCP, for example, applications can easily serve internal
traffic/dsts in DCTCP and external one with CUBIC. Other scenarios
would also allow for utilizing e.g. long living, low priority
background flows for certain destinations/routes while still being
able for normal traffic to utilize the default congestion control
algorithm. We also thought about a per netns setting (where different
defaults are possible), but given its actually a link specific
property, we argue that a per route/destination setting is the most
natural and flexible.
The administrator can utilize this through ip-route(8) by appending
"congctl [lock] <name>", where <name> denotes the name of a
congestion control algorithm and the optional lock parameter allows
to enforce the given algorithm so that applications in user space
would not be allowed to overwrite that algorithm for that destination.
The dst metric lookups are being done when a dst entry is already
available in order to avoid a costly lookup and still before the
algorithms are being initialized, thus overhead is very low when the
feature is not being used. While the client side would need to drop
the current reference on the module, on server side this can actually
even be avoided as we just got a flat-copied socket clone.
Joint work with Florian Westphal.
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:48 +03:00
static inline bool tcp_ca_dst_locked ( const struct dst_entry * dst )
{
return dst_metric_locked ( dst , RTAX_CC_ALGO ) ;
}
2015-10-17 07:57:42 +03:00
/* Minimum RTT in usec. ~0 means not available. */
static inline u32 tcp_min_rtt ( const struct tcp_sock * tp )
{
2016-09-20 06:39:10 +03:00
return minmax_get ( & tp - > rtt_min ) ;
2015-10-17 07:57:42 +03:00
}
2005-04-17 02:20:36 +04:00
/* Compute the actual receive window we are currently advertising.
* Rcv_nxt can be after the window if our peer push more data
* than the offered window .
*/
2006-01-04 03:03:49 +03:00
static inline u32 tcp_receive_window ( const struct tcp_sock * tp )
2005-04-17 02:20:36 +04:00
{
s32 win = tp - > rcv_wup + tp - > rcv_wnd - tp - > rcv_nxt ;
if ( win < 0 )
win = 0 ;
return ( u32 ) win ;
}
/* Choose a new window, without checks for shrinking, and without
* scaling applied to the result . The caller does these things
* if necessary . This is a " raw " window selection .
*/
2013-09-23 22:33:32 +04:00
u32 __tcp_select_window ( struct sock * sk ) ;
2005-04-17 02:20:36 +04:00
2012-04-19 07:40:39 +04:00
void tcp_send_window_probe ( struct sock * sk ) ;
2017-05-17 00:00:01 +03:00
/* TCP uses 32bit jiffies to save some space.
* Note that this is different from tcp_time_stamp , which
* historically has been the same until linux - 4.13 .
*/
# define tcp_jiffies32 ((u32)jiffies)
2017-05-17 00:00:14 +03:00
/*
* Deliver a 32 bit value for TCP timestamp option ( RFC 7323 )
* It is no longer tied to jiffies , but to 1 ms clock .
* Note : double check if you want to use tcp_jiffies32 instead of this .
*/
# define TCP_TS_HZ 1000
static inline u64 tcp_clock_ns ( void )
{
2018-09-28 20:28:44 +03:00
return ktime_get_ns ( ) ;
2017-05-17 00:00:14 +03:00
}
static inline u64 tcp_clock_us ( void )
{
return div_u64 ( tcp_clock_ns ( ) , NSEC_PER_USEC ) ;
}
/* This should only be used in contexts where tp->tcp_mstamp is up to date */
static inline u32 tcp_time_stamp ( const struct tcp_sock * tp )
{
return div_u64 ( tp - > tcp_mstamp , USEC_PER_SEC / TCP_TS_HZ ) ;
}
2019-11-07 22:51:18 +03:00
/* Convert a nsec timestamp into TCP TSval timestamp (ms based currently) */
static inline u32 tcp_ns_to_ts ( u64 ns )
{
return div_u64 ( ns , NSEC_PER_SEC / TCP_TS_HZ ) ;
}
2017-05-17 00:00:14 +03:00
/* Could use tcp_clock_us() / 1000, but this version uses a single divide */
static inline u32 tcp_time_stamp_raw ( void )
{
2019-11-07 22:51:18 +03:00
return tcp_ns_to_ts ( tcp_clock_ns ( ) ) ;
2017-05-17 00:00:14 +03:00
}
2018-09-21 18:51:49 +03:00
void tcp_mstamp_refresh ( struct tcp_sock * tp ) ;
2017-05-17 00:00:14 +03:00
static inline u32 tcp_stamp_us_delta ( u64 t1 , u64 t0 )
{
return max_t ( s64 , t1 - t0 , 0 ) ;
}
2005-04-17 02:20:36 +04:00
2014-09-06 02:33:33 +04:00
static inline u32 tcp_skb_timestamp ( const struct sk_buff * skb )
{
2019-11-07 22:51:18 +03:00
return tcp_ns_to_ts ( skb - > skb_mstamp_ns ) ;
2014-09-06 02:33:33 +04:00
}
2018-09-21 18:51:47 +03:00
/* provide the departure time in us unit */
static inline u64 tcp_skb_timestamp_us ( const struct sk_buff * skb )
{
2018-09-21 18:51:50 +03:00
return div_u64 ( skb - > skb_mstamp_ns , NSEC_PER_USEC ) ;
2018-09-21 18:51:47 +03:00
}
2014-09-06 02:33:33 +04:00
2010-06-12 18:01:43 +04:00
# define tcp_flag_byte(th) (((u_int8_t *)th)[13])
# define TCPHDR_FIN 0x01
# define TCPHDR_SYN 0x02
# define TCPHDR_RST 0x04
# define TCPHDR_PSH 0x08
# define TCPHDR_ACK 0x10
# define TCPHDR_URG 0x20
# define TCPHDR_ECE 0x40
# define TCPHDR_CWR 0x80
tcp: add rfc3168, section 6.1.1.1. fallback
This work as a follow-up of commit f7b3bec6f516 ("net: allow setting ecn
via routing table") and adds RFC3168 section 6.1.1.1. fallback for outgoing
ECN connections. In other words, this work adds a retry with a non-ECN
setup SYN packet, as suggested from the RFC on the first timeout:
[...] A host that receives no reply to an ECN-setup SYN within the
normal SYN retransmission timeout interval MAY resend the SYN and
any subsequent SYN retransmissions with CWR and ECE cleared. [...]
Schematic client-side view when assuming the server is in tcp_ecn=2 mode,
that is, Linux default since 2009 via commit 255cac91c3c9 ("tcp: extend
ECN sysctl to allow server-side only ECN"):
1) Normal ECN-capable path:
SYN ECE CWR ----->
<----- SYN ACK ECE
ACK ----->
2) Path with broken middlebox, when client has fallback:
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ----->
<----- SYN ACK
ACK ----->
In case we would not have the fallback implemented, the middlebox drop
point would basically end up as:
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
SYN ECE CWR ----X crappy middlebox drops packet
(timeout, rtx)
In any case, it's rather a smaller percentage of sites where there would
occur such additional setup latency: it was found in end of 2014 that ~56%
of IPv4 and 65% of IPv6 servers of Alexa 1 million list would negotiate
ECN (aka tcp_ecn=2 default), 0.42% of these webservers will fail to connect
when trying to negotiate with ECN (tcp_ecn=1) due to timeouts, which the
fallback would mitigate with a slight latency trade-off. Recent related
paper on this topic:
Brian Trammell, Mirja Kühlewind, Damiano Boppart, Iain Learmonth,
Gorry Fairhurst, and Richard Scheffenegger:
"Enabling Internet-Wide Deployment of Explicit Congestion Notification."
Proc. PAM 2015, New York.
http://ecn.ethz.ch/ecn-pam15.pdf
Thus, when net.ipv4.tcp_ecn=1 is being set, the patch will perform RFC3168,
section 6.1.1.1. fallback on timeout. For users explicitly not wanting this
which can be in DC use case, we add a net.ipv4.tcp_ecn_fallback knob that
allows for disabling the fallback.
tp->ecn_flags are not being cleared in tcp_ecn_clear_syn() on output, but
rather we let tcp_ecn_rcv_synack() take that over on input path in case a
SYN ACK ECE was delayed. Thus a spurious SYN retransmission will not prevent
ECN being negotiated eventually in that case.
Reference: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
Reference: https://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
Signed-off-by: Brian Trammell <trammell@tik.ee.ethz.ch>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Dave That <dave.taht@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-19 22:04:22 +03:00
# define TCPHDR_SYN_ECN (TCPHDR_SYN | TCPHDR_ECE | TCPHDR_CWR)
2005-11-11 04:13:47 +03:00
/* This is what the send packet queuing engine uses to pass
2010-07-16 08:41:00 +04:00
* TCP per - packet control information to the transmission code .
* We also store the host - order sequence numbers in here too .
* This is 44 bytes if IPV6 is enabled .
* If this grows please adjust skbuff . h : skbuff - > cb [ xxx ] size appropriately .
2005-04-17 02:20:36 +04:00
*/
struct tcp_skb_cb {
__u32 seq ; /* Starting sequence number */
__u32 end_seq ; /* SEQ + FIN + SYN + datalen */
2014-09-24 15:11:22 +04:00
union {
/* Note : tcp_tw_isn is used in input path only
* ( isn chosen by tcp_timewait_state_process ( ) )
*
2015-06-11 19:15:18 +03:00
* tcp_gso_segs / size are used in write queue only ,
* cf tcp_skb_pcount ( ) / tcp_skb_mss ( )
2014-09-24 15:11:22 +04:00
*/
__u32 tcp_tw_isn ;
2015-06-11 19:15:18 +03:00
struct {
u16 tcp_gso_segs ;
u16 tcp_gso_size ;
} ;
2014-09-24 15:11:22 +04:00
} ;
2011-09-27 21:25:05 +04:00
__u8 tcp_flags ; /* TCP header flags. (tcp[13]) */
2012-04-16 11:08:06 +04:00
2017-11-09 00:01:26 +03:00
__u8 sacked ; /* State flags for SACK. */
2005-04-17 02:20:36 +04:00
# define TCPCB_SACKED_ACKED 0x01 /* SKB ACK'd by a SACK block */
# define TCPCB_SACKED_RETRANS 0x02 /* SKB retransmitted */
# define TCPCB_LOST 0x04 /* SKB is lost */
# define TCPCB_TAGBITS 0x07 /* All tag bits */
2018-09-21 18:51:50 +03:00
# define TCPCB_REPAIRED 0x10 /* SKB repaired (no skb_mstamp_ns) */
2005-04-17 02:20:36 +04:00
# define TCPCB_EVER_RETRANS 0x80 /* Ever retransmitted frame */
2014-08-13 16:03:10 +04:00
# define TCPCB_RETRANS (TCPCB_SACKED_RETRANS|TCPCB_EVER_RETRANS| \
TCPCB_REPAIRED )
2005-04-17 02:20:36 +04:00
2012-04-16 11:08:06 +04:00
__u8 ip_dsfield ; /* IPv4 tos or IPv6 dsfield */
2016-04-03 06:08:08 +03:00
__u8 txstamp_ack : 1 , /* Record TX timestamp for ack? */
tcp: Make use of MSG_EOR in tcp_sendmsg
This patch adds an eor bit to the TCP_SKB_CB. When MSG_EOR
is passed to tcp_sendmsg, the eor bit will be set at the skb
containing the last byte of the userland's msg. The eor bit
will prevent data from appending to that skb in the future.
The change in do_tcp_sendpages is to honor the eor set
during the previous tcp_sendmsg(MSG_EOR) call.
This patch handles the tcp_sendmsg case. The followup patches
will handle other skb coalescing and fragment cases.
One potential use case is to use MSG_EOR with
SOF_TIMESTAMPING_TX_ACK to get a more accurate
TCP ack timestamping on application protocol with
multiple outgoing response messages (e.g. HTTP2).
Packetdrill script for testing:
~~~~~~
+0 `sysctl -q -w net.ipv4.tcp_min_tso_segs=10`
+0 `sysctl -q -w net.ipv4.tcp_no_metrics_save=1`
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
0.100 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
0.100 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
0.200 write(4, ..., 14600) = 14600
0.200 sendto(4, ..., 730, MSG_EOR, ..., ...) = 730
0.200 sendto(4, ..., 730, MSG_EOR, ..., ...) = 730
0.200 > . 1:7301(7300) ack 1
0.200 > P. 7301:14601(7300) ack 1
0.300 < . 1:1(0) ack 14601 win 257
0.300 > P. 14601:15331(730) ack 1
0.300 > P. 15331:16061(730) ack 1
0.400 < . 1:1(0) ack 16061 win 257
0.400 close(4) = 0
0.400 > F. 16061:16061(0) ack 1
0.400 < F. 1:1(0) ack 16062 win 257
0.400 > . 16062:16062(0) ack 2
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-26 00:44:48 +03:00
eor : 1 , /* Is skb MSG_EOR marked? */
2017-08-23 00:08:48 +03:00
has_rxtstamp : 1 , /* SKB has a RX timestamp */
unused : 5 ;
2005-04-17 02:20:36 +04:00
__u32 ack_seq ; /* Sequence number ACK'd */
2014-09-27 20:50:57 +04:00
union {
2016-05-07 06:35:35 +03:00
struct {
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
/* There is space for up to 24 bytes */
2016-09-20 06:39:15 +03:00
__u32 in_flight : 30 , /* Bytes in flight at transmit */
is_app_limited : 1 , /* cwnd not fully used? */
unused : 1 ;
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
/* pkts S/ACKed so far upon tx of skb, incl retrans: */
__u32 delivered ;
/* start of send pipeline phase */
2017-05-17 00:00:14 +03:00
u64 first_tx_mstamp ;
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
/* when we reached the "delivered" count */
2017-05-17 00:00:14 +03:00
u64 delivered_mstamp ;
2016-05-07 06:35:35 +03:00
} tx ; /* only used for outgoing skbs */
union {
struct inet_skb_parm h4 ;
2014-09-27 20:50:57 +04:00
# if IS_ENABLED(CONFIG_IPV6)
2016-05-07 06:35:35 +03:00
struct inet6_skb_parm h6 ;
2014-09-27 20:50:57 +04:00
# endif
2016-05-07 06:35:35 +03:00
} header ; /* For incoming skbs */
2017-10-18 17:10:36 +03:00
struct {
__u32 flags ;
2018-05-14 20:00:16 +03:00
struct sock * sk_redir ;
2017-10-27 19:45:34 +03:00
void * data_end ;
2017-10-18 17:10:36 +03:00
} bpf ;
2016-05-07 06:35:35 +03:00
} ;
2005-04-17 02:20:36 +04:00
} ;
# define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)->cb[0]))
bpf: sockmap, convert bpf_compute_data_pointers to bpf_*_sk_skb
In commit
'bpf: bpf_compute_data uses incorrect cb structure' (8108a7751512)
we added the routine bpf_compute_data_end_sk_skb() to compute the
correct data_end values, but this has since been lost. In kernel
v4.14 this was correct and the above patch was applied in it
entirety. Then when v4.14 was merged into v4.15-rc1 net-next tree
we lost the piece that renamed bpf_compute_data_pointers to the
new function bpf_compute_data_end_sk_skb. This was done here,
e1ea2f9856b7 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
When it conflicted with the following rename patch,
6aaae2b6c433 ("bpf: rename bpf_compute_data_end into bpf_compute_data_pointers")
Finally, after a refactor I thought even the function
bpf_compute_data_end_sk_skb() was no longer needed and it was
erroneously removed.
However, we never reverted the sk_skb_convert_ctx_access() usage of
tcp_skb_cb which had been committed and survived the merge conflict.
Here we fix this by adding back the helper and *_data_end_sk_skb()
usage. Using the bpf_skc_data_end mapping is not correct because it
expects a qdisc_skb_cb object but at the sock layer this is not the
case. Even though it happens to work here because we don't overwrite
any data in-use at the socket layer and the cb structure is cleared
later this has potential to create some subtle issues. But, even
more concretely the filter.c access check uses tcp_skb_cb.
And by some act of chance though,
struct bpf_skb_data_end {
struct qdisc_skb_cb qdisc_cb; /* 0 28 */
/* XXX 4 bytes hole, try to pack */
void * data_meta; /* 32 8 */
void * data_end; /* 40 8 */
/* size: 48, cachelines: 1, members: 3 */
/* sum members: 44, holes: 1, sum holes: 4 */
/* last cacheline: 48 bytes */
};
and then tcp_skb_cb,
struct tcp_skb_cb {
[...]
struct {
__u32 flags; /* 24 4 */
struct sock * sk_redir; /* 32 8 */
void * data_end; /* 40 8 */
} bpf; /* 24 */
};
So when we use offset_of() to track down the byte offset we get 40 in
either case and everything continues to work. Fix this mess and use
correct structures its unclear how long this might actually work for
until someone moves the structs around.
Reported-by: Martin KaFai Lau <kafai@fb.com>
Fixes: e1ea2f9856b7 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
Fixes: 6aaae2b6c433 ("bpf: rename bpf_compute_data_end into bpf_compute_data_pointers")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-07-05 18:50:15 +03:00
static inline void bpf_compute_data_end_sk_skb ( struct sk_buff * skb )
{
TCP_SKB_CB ( skb ) - > bpf . data_end = skb - > data + skb_headlen ( skb ) ;
}
2014-10-17 20:17:20 +04:00
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 03:45:58 +03:00
static inline bool tcp_skb_bpf_ingress ( const struct sk_buff * skb )
{
return TCP_SKB_CB ( skb ) - > bpf . flags & BPF_F_INGRESS ;
}
static inline struct sock * tcp_skb_bpf_redirect_fetch ( struct sk_buff * skb )
{
return TCP_SKB_CB ( skb ) - > bpf . sk_redir ;
}
static inline void tcp_skb_bpf_redirect_clear ( struct sk_buff * skb )
{
TCP_SKB_CB ( skb ) - > bpf . sk_redir = NULL ;
}
2014-10-18 19:34:37 +04:00
# if IS_ENABLED(CONFIG_IPV6)
2014-10-17 20:17:20 +04:00
/* This is the variant of inet6_iif() that must be used by TCP,
* as TCP moves IP6CB into a different location in skb - > cb [ ]
*/
static inline int tcp_v6_iif ( const struct sk_buff * skb )
2018-07-19 22:41:18 +03:00
{
return TCP_SKB_CB ( skb ) - > header . h6 . iif ;
}
static inline int tcp_v6_iif_l3_slave ( const struct sk_buff * skb )
2014-10-17 20:17:20 +04:00
{
2016-10-17 06:02:52 +03:00
bool l3_slave = ipv6_l3mdev_skb ( TCP_SKB_CB ( skb ) - > header . h6 . flags ) ;
2016-05-10 21:19:50 +03:00
return l3_slave ? skb - > skb_iif : TCP_SKB_CB ( skb ) - > header . h6 . iif ;
2014-10-17 20:17:20 +04:00
}
2017-08-07 18:44:21 +03:00
/* TCP_SKB_CB reference means this can not be used from early demux */
static inline int tcp_v6_sdif ( const struct sk_buff * skb )
{
# if IS_ENABLED(CONFIG_NET_L3_MASTER_DEV)
if ( skb & & ipv6_l3mdev_skb ( TCP_SKB_CB ( skb ) - > header . h6 . flags ) )
return TCP_SKB_CB ( skb ) - > header . h6 . iif ;
# endif
return 0 ;
}
2014-10-18 19:34:37 +04:00
# endif
2014-10-17 20:17:20 +04:00
2016-10-17 06:02:52 +03:00
static inline bool inet_exact_dif_match ( struct net * net , struct sk_buff * skb )
{
# if IS_ENABLED(CONFIG_NET_L3_MASTER_DEV)
if ( ! net - > ipv4 . sysctl_tcp_l3mdev_accept & &
2017-12-03 20:33:00 +03:00
skb & & ipv4_l3mdev_skb ( IPCB ( skb ) - > flags ) )
2016-10-17 06:02:52 +03:00
return true ;
# endif
return false ;
}
2017-08-07 18:44:17 +03:00
/* TCP_SKB_CB reference means this can not be used from early demux */
static inline int tcp_v4_sdif ( struct sk_buff * skb )
{
# if IS_ENABLED(CONFIG_NET_L3_MASTER_DEV)
if ( skb & & ipv4_l3mdev_skb ( TCP_SKB_CB ( skb ) - > header . h4 . flags ) )
return TCP_SKB_CB ( skb ) - > header . h4 . iif ;
# endif
return 0 ;
}
2005-04-17 02:20:36 +04:00
/* Due to TSO, an SKB can be composed of multiple actual
* packets . To keep these tracked properly , we use this .
2012-05-04 09:14:02 +04:00
*/
2005-04-17 02:20:36 +04:00
static inline int tcp_skb_pcount ( const struct sk_buff * skb )
2012-05-04 09:14:02 +04:00
{
2014-09-24 15:11:22 +04:00
return TCP_SKB_CB ( skb ) - > tcp_gso_segs ;
}
2012-05-04 09:14:02 +04:00
2014-09-24 15:11:22 +04:00
static inline void tcp_skb_pcount_set ( struct sk_buff * skb , int segs )
{
TCP_SKB_CB ( skb ) - > tcp_gso_segs = segs ;
2012-05-04 09:14:02 +04:00
}
2014-09-24 15:11:22 +04:00
static inline void tcp_skb_pcount_add ( struct sk_buff * skb , int segs )
2005-04-17 02:20:36 +04:00
{
2014-09-24 15:11:22 +04:00
TCP_SKB_CB ( skb ) - > tcp_gso_segs + = segs ;
2005-04-17 02:20:36 +04:00
}
2015-06-11 19:15:18 +03:00
/* This is valid iff skb is in write queue and tcp_skb_pcount() > 1. */
2005-04-17 02:20:36 +04:00
static inline int tcp_skb_mss ( const struct sk_buff * skb )
{
2015-06-11 19:15:18 +03:00
return TCP_SKB_CB ( skb ) - > tcp_gso_size ;
2005-04-17 02:20:36 +04:00
}
tcp: Make use of MSG_EOR in tcp_sendmsg
This patch adds an eor bit to the TCP_SKB_CB. When MSG_EOR
is passed to tcp_sendmsg, the eor bit will be set at the skb
containing the last byte of the userland's msg. The eor bit
will prevent data from appending to that skb in the future.
The change in do_tcp_sendpages is to honor the eor set
during the previous tcp_sendmsg(MSG_EOR) call.
This patch handles the tcp_sendmsg case. The followup patches
will handle other skb coalescing and fragment cases.
One potential use case is to use MSG_EOR with
SOF_TIMESTAMPING_TX_ACK to get a more accurate
TCP ack timestamping on application protocol with
multiple outgoing response messages (e.g. HTTP2).
Packetdrill script for testing:
~~~~~~
+0 `sysctl -q -w net.ipv4.tcp_min_tso_segs=10`
+0 `sysctl -q -w net.ipv4.tcp_no_metrics_save=1`
+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
0.100 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 7>
0.100 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 7>
0.200 < . 1:1(0) ack 1 win 257
0.200 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0
0.200 write(4, ..., 14600) = 14600
0.200 sendto(4, ..., 730, MSG_EOR, ..., ...) = 730
0.200 sendto(4, ..., 730, MSG_EOR, ..., ...) = 730
0.200 > . 1:7301(7300) ack 1
0.200 > P. 7301:14601(7300) ack 1
0.300 < . 1:1(0) ack 14601 win 257
0.300 > P. 14601:15331(730) ack 1
0.300 > P. 15331:16061(730) ack 1
0.400 < . 1:1(0) ack 16061 win 257
0.400 close(4) = 0
0.400 > F. 16061:16061(0) ack 1
0.400 < F. 1:1(0) ack 16062 win 257
0.400 > . 16062:16062(0) ack 2
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Soheil Hassas Yeganeh <soheil@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-26 00:44:48 +03:00
static inline bool tcp_skb_can_collapse_to ( const struct sk_buff * skb )
{
return likely ( ! TCP_SKB_CB ( skb ) - > eor ) ;
}
2020-01-09 18:59:20 +03:00
static inline bool tcp_skb_can_collapse ( const struct sk_buff * to ,
const struct sk_buff * from )
{
return likely ( tcp_skb_can_collapse_to ( to ) & &
mptcp_skb_can_collapse ( to , from ) ) ;
}
2005-06-23 23:19:55 +04:00
/* Events passed to congestion control interface */
enum tcp_ca_event {
CA_EVENT_TX_START , /* first transmit when no packets in flight */
CA_EVENT_CWND_RESTART , /* congestion window restart */
CA_EVENT_COMPLETE_CWR , /* end of congestion recovery */
CA_EVENT_LOSS , /* loss timeout */
2014-09-27 00:37:35 +04:00
CA_EVENT_ECN_NO_CE , /* ECT set, but not CE marked */
CA_EVENT_ECN_IS_CE , /* received CE marked IP packet */
2014-09-27 00:37:34 +04:00
} ;
2014-09-27 00:37:35 +04:00
/* Information about inbound ACK, passed to cong_ops->in_ack_event() */
2014-09-27 00:37:34 +04:00
enum tcp_ca_ack_event_flags {
2017-08-30 20:24:57 +03:00
CA_ACK_SLOWPATH = ( 1 < < 0 ) , /* In slow path processing */
CA_ACK_WIN_UPDATE = ( 1 < < 1 ) , /* ACK updated window */
CA_ACK_ECE = ( 1 < < 2 ) , /* ECE bit is set on ack */
2005-06-23 23:19:55 +04:00
} ;
/*
* Interface for adding new TCP congestion control handlers
*/
# define TCP_CA_NAME_MAX 16
2006-11-10 03:32:06 +03:00
# define TCP_CA_MAX 128
# define TCP_CA_BUF_MAX (TCP_CA_NAME_MAX*TCP_CA_MAX)
net: tcp: add key management to congestion control
This patch adds necessary infrastructure to the congestion control
framework for later per route congestion control support.
For a per route congestion control possibility, our aim is to store
a unique u32 key identifier into dst metrics, which can then be
mapped into a tcp_congestion_ops struct. We argue that having a
RTAX key entry is the most simple, generic and easy way to manage,
and also keeps the memory footprint of dst entries lower on 64 bit
than with storing a pointer directly, for example. Having a unique
key id also allows for decoupling actual TCP congestion control
module management from the FIB layer, i.e. we don't have to care
about expensive module refcounting inside the FIB at this point.
We first thought of using an IDR store for the realization, which
takes over dynamic assignment of unused key space and also performs
the key to pointer mapping in RCU. While doing so, we stumbled upon
the issue that due to the nature of dynamic key distribution, it
just so happens, arguably in very rare occasions, that excessive
module loads and unloads can lead to a possible reuse of previously
used key space. Thus, previously stale keys in the dst metric are
now being reassigned to a different congestion control algorithm,
which might lead to unexpected behaviour. One way to resolve this
would have been to walk FIBs on the actually rare occasion of a
module unload and reset the metric keys for each FIB in each netns,
but that's just very costly.
Therefore, we argue a better solution is to reuse the unique
congestion control algorithm name member and map that into u32 key
space through jhash. For that, we split the flags attribute (as it
currently uses 2 bits only anyway) into two u32 attributes, flags
and key, so that we can keep the cacheline boundary of 2 cachelines
on x86_64 and cache the precalculated key at registration time for
the fast path. On average we might expect 2 - 4 modules being loaded
worst case perhaps 15, so a key collision possibility is extremely
low, and guaranteed collision-free on LE/BE for all in-tree modules.
Overall this results in much simpler code, and all without the
overhead of an IDR. Due to the deterministic nature, modules can
now be unloaded, the congestion control algorithm for a specific
but unloaded key will fall back to the default one, and on module
reload time it will switch back to the expected algorithm
transparently.
Joint work with Florian Westphal.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:46 +03:00
# define TCP_CA_UNSPEC 0
2014-09-27 00:37:33 +04:00
/* Algorithm can be set on socket without CAP_NET_ADMIN privileges */
2007-04-24 09:26:16 +04:00
# define TCP_CONG_NON_RESTRICTED 0x1
2014-09-27 00:37:33 +04:00
/* Requires ECN/ECT set on all packets */
# define TCP_CONG_NEEDS_ECN 0x2
2020-01-09 03:35:08 +03:00
# define TCP_CONG_MASK (TCP_CONG_NON_RESTRICTED | TCP_CONG_NEEDS_ECN)
2007-04-24 09:26:16 +04:00
2015-04-29 02:23:48 +03:00
union tcp_cc_info ;
2016-05-11 20:02:13 +03:00
struct ack_sample {
u32 pkts_acked ;
s32 rtt_us ;
2016-06-09 07:16:44 +03:00
u32 in_flight ;
2016-05-11 20:02:13 +03:00
} ;
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
/* A rate sample measures the number of (original/retransmitted) data
* packets delivered " delivered " over an interval of time " interval_us " .
* The tcp_rate . c code fills in the rate sample , and congestion
* control modules that define a cong_control function to run at the end
* of ACK processing can optionally chose to consult this sample when
* setting cwnd and pacing rate .
* A sample is invalid if " delivered " or " interval_us " is negative .
*/
struct rate_sample {
2017-05-17 00:00:14 +03:00
u64 prior_mstamp ; /* starting timestamp for interval */
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
u32 prior_delivered ; /* tp->delivered at "prior_mstamp" */
s32 delivered ; /* number of packets delivered over interval */
long interval_us ; /* time for tp->delivered to incr "delivered" */
2018-07-09 20:53:39 +03:00
u32 snd_interval_us ; /* snd interval for delivered packets */
u32 rcv_interval_us ; /* rcv interval for delivered packets */
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
long rtt_us ; /* RTT of last (S)ACKed packet (or -1) */
int losses ; /* number of packets marked lost upon ACK */
u32 acked_sacked ; /* number of packets newly (S)ACKed upon ACK */
u32 prior_in_flight ; /* in flight before this ACK */
2016-09-20 06:39:15 +03:00
bool is_app_limited ; /* is sample from packet with bubble in pipe? */
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
bool is_retrans ; /* is sample from retransmission? */
2018-01-17 23:11:01 +03:00
bool is_ack_delayed ; /* is this (likely) a delayed ACK? */
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
} ;
2005-06-23 23:19:55 +04:00
struct tcp_congestion_ops {
struct list_head list ;
net: tcp: add key management to congestion control
This patch adds necessary infrastructure to the congestion control
framework for later per route congestion control support.
For a per route congestion control possibility, our aim is to store
a unique u32 key identifier into dst metrics, which can then be
mapped into a tcp_congestion_ops struct. We argue that having a
RTAX key entry is the most simple, generic and easy way to manage,
and also keeps the memory footprint of dst entries lower on 64 bit
than with storing a pointer directly, for example. Having a unique
key id also allows for decoupling actual TCP congestion control
module management from the FIB layer, i.e. we don't have to care
about expensive module refcounting inside the FIB at this point.
We first thought of using an IDR store for the realization, which
takes over dynamic assignment of unused key space and also performs
the key to pointer mapping in RCU. While doing so, we stumbled upon
the issue that due to the nature of dynamic key distribution, it
just so happens, arguably in very rare occasions, that excessive
module loads and unloads can lead to a possible reuse of previously
used key space. Thus, previously stale keys in the dst metric are
now being reassigned to a different congestion control algorithm,
which might lead to unexpected behaviour. One way to resolve this
would have been to walk FIBs on the actually rare occasion of a
module unload and reset the metric keys for each FIB in each netns,
but that's just very costly.
Therefore, we argue a better solution is to reuse the unique
congestion control algorithm name member and map that into u32 key
space through jhash. For that, we split the flags attribute (as it
currently uses 2 bits only anyway) into two u32 attributes, flags
and key, so that we can keep the cacheline boundary of 2 cachelines
on x86_64 and cache the precalculated key at registration time for
the fast path. On average we might expect 2 - 4 modules being loaded
worst case perhaps 15, so a key collision possibility is extremely
low, and guaranteed collision-free on LE/BE for all in-tree modules.
Overall this results in much simpler code, and all without the
overhead of an IDR. Due to the deterministic nature, modules can
now be unloaded, the congestion control algorithm for a specific
but unloaded key will fall back to the default one, and on module
reload time it will switch back to the expected algorithm
transparently.
Joint work with Florian Westphal.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:46 +03:00
u32 key ;
u32 flags ;
2005-06-23 23:19:55 +04:00
/* initialize private data (optional) */
2005-08-10 11:03:31 +04:00
void ( * init ) ( struct sock * sk ) ;
2005-06-23 23:19:55 +04:00
/* cleanup private data (optional) */
2005-08-10 11:03:31 +04:00
void ( * release ) ( struct sock * sk ) ;
2005-06-23 23:19:55 +04:00
/* return slow start threshold (required) */
2005-08-10 11:03:31 +04:00
u32 ( * ssthresh ) ( struct sock * sk ) ;
2005-06-23 23:19:55 +04:00
/* do new cwnd calculation (required) */
2014-05-03 08:18:05 +04:00
void ( * cong_avoid ) ( struct sock * sk , u32 ack , u32 acked ) ;
2005-06-23 23:19:55 +04:00
/* call before changing ca_state (optional) */
2005-08-10 11:03:31 +04:00
void ( * set_state ) ( struct sock * sk , u8 new_state ) ;
2005-06-23 23:19:55 +04:00
/* call when cwnd event occurs (optional) */
2005-08-10 11:03:31 +04:00
void ( * cwnd_event ) ( struct sock * sk , enum tcp_ca_event ev ) ;
2014-09-27 00:37:34 +04:00
/* call when ack arrives (optional) */
void ( * in_ack_event ) ( struct sock * sk , u32 flags ) ;
2017-06-03 15:10:54 +03:00
/* new value of cwnd after loss (required) */
2005-08-10 11:03:31 +04:00
u32 ( * undo_cwnd ) ( struct sock * sk ) ;
2005-06-23 23:19:55 +04:00
/* hook for packet ack accounting (optional) */
2016-05-11 20:02:13 +03:00
void ( * pkts_acked ) ( struct sock * sk , const struct ack_sample * sample ) ;
2018-03-01 01:40:46 +03:00
/* override sysctl_tcp_min_tso_segs */
u32 ( * min_tso_segs ) ( struct sock * sk ) ;
2016-09-20 06:39:20 +03:00
/* returns the multiplier used in tcp_sndbuf_expand (optional) */
u32 ( * sndbuf_expand ) ( struct sock * sk ) ;
2016-09-20 06:39:21 +03:00
/* call when packets are delivered to update cwnd and pacing rate,
* after all the ca_state processing . ( optional )
*/
void ( * cong_control ) ( struct sock * sk , const struct rate_sample * rs ) ;
2005-08-12 19:51:49 +04:00
/* get info for inet_diag (optional) */
2015-04-29 02:23:48 +03:00
size_t ( * get_info ) ( struct sock * sk , u32 ext , int * attr ,
union tcp_cc_info * info ) ;
2005-06-23 23:19:55 +04:00
char name [ TCP_CA_NAME_MAX ] ;
struct module * owner ;
} ;
2013-09-23 22:33:32 +04:00
int tcp_register_congestion_control ( struct tcp_congestion_ops * type ) ;
void tcp_unregister_congestion_control ( struct tcp_congestion_ops * type ) ;
2005-06-23 23:19:55 +04:00
2014-09-27 00:37:32 +04:00
void tcp_assign_congestion_control ( struct sock * sk ) ;
2013-09-23 22:33:32 +04:00
void tcp_init_congestion_control ( struct sock * sk ) ;
void tcp_cleanup_congestion_control ( struct sock * sk ) ;
2017-11-14 19:25:49 +03:00
int tcp_set_default_congestion_control ( struct net * net , const char * name ) ;
void tcp_get_default_congestion_control ( struct net * net , char * name ) ;
2013-09-23 22:33:32 +04:00
void tcp_get_available_congestion_control ( char * buf , size_t len ) ;
void tcp_get_allowed_congestion_control ( char * buf , size_t len ) ;
int tcp_set_allowed_congestion_control ( char * allowed ) ;
2019-07-19 05:28:14 +03:00
int tcp_set_congestion_control ( struct sock * sk , const char * name , bool load ,
bool reinit , bool cap_net_admin ) ;
2015-01-29 04:01:35 +03:00
u32 tcp_slow_start ( struct tcp_sock * tp , u32 acked ) ;
void tcp_cong_avoid_ai ( struct tcp_sock * tp , u32 w , u32 acked ) ;
2005-06-23 23:19:55 +04:00
2013-09-23 22:33:32 +04:00
u32 tcp_reno_ssthresh ( struct sock * sk ) ;
2016-11-21 16:18:38 +03:00
u32 tcp_reno_undo_cwnd ( struct sock * sk ) ;
2014-05-03 08:18:05 +04:00
void tcp_reno_cong_avoid ( struct sock * sk , u32 ack , u32 acked ) ;
2005-06-24 10:45:02 +04:00
extern struct tcp_congestion_ops tcp_reno ;
2005-06-23 23:19:55 +04:00
2020-01-09 03:35:08 +03:00
struct tcp_congestion_ops * tcp_ca_find ( const char * name ) ;
net: tcp: add key management to congestion control
This patch adds necessary infrastructure to the congestion control
framework for later per route congestion control support.
For a per route congestion control possibility, our aim is to store
a unique u32 key identifier into dst metrics, which can then be
mapped into a tcp_congestion_ops struct. We argue that having a
RTAX key entry is the most simple, generic and easy way to manage,
and also keeps the memory footprint of dst entries lower on 64 bit
than with storing a pointer directly, for example. Having a unique
key id also allows for decoupling actual TCP congestion control
module management from the FIB layer, i.e. we don't have to care
about expensive module refcounting inside the FIB at this point.
We first thought of using an IDR store for the realization, which
takes over dynamic assignment of unused key space and also performs
the key to pointer mapping in RCU. While doing so, we stumbled upon
the issue that due to the nature of dynamic key distribution, it
just so happens, arguably in very rare occasions, that excessive
module loads and unloads can lead to a possible reuse of previously
used key space. Thus, previously stale keys in the dst metric are
now being reassigned to a different congestion control algorithm,
which might lead to unexpected behaviour. One way to resolve this
would have been to walk FIBs on the actually rare occasion of a
module unload and reset the metric keys for each FIB in each netns,
but that's just very costly.
Therefore, we argue a better solution is to reuse the unique
congestion control algorithm name member and map that into u32 key
space through jhash. For that, we split the flags attribute (as it
currently uses 2 bits only anyway) into two u32 attributes, flags
and key, so that we can keep the cacheline boundary of 2 cachelines
on x86_64 and cache the precalculated key at registration time for
the fast path. On average we might expect 2 - 4 modules being loaded
worst case perhaps 15, so a key collision possibility is extremely
low, and guaranteed collision-free on LE/BE for all in-tree modules.
Overall this results in much simpler code, and all without the
overhead of an IDR. Due to the deterministic nature, modules can
now be unloaded, the congestion control algorithm for a specific
but unloaded key will fall back to the default one, and on module
reload time it will switch back to the expected algorithm
transparently.
Joint work with Florian Westphal.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:46 +03:00
struct tcp_congestion_ops * tcp_ca_find_key ( u32 key ) ;
2017-11-14 19:25:49 +03:00
u32 tcp_ca_get_key_by_name ( struct net * net , const char * name , bool * ecn_ca ) ;
2015-01-06 01:57:47 +03:00
# ifdef CONFIG_INET
net: tcp: add key management to congestion control
This patch adds necessary infrastructure to the congestion control
framework for later per route congestion control support.
For a per route congestion control possibility, our aim is to store
a unique u32 key identifier into dst metrics, which can then be
mapped into a tcp_congestion_ops struct. We argue that having a
RTAX key entry is the most simple, generic and easy way to manage,
and also keeps the memory footprint of dst entries lower on 64 bit
than with storing a pointer directly, for example. Having a unique
key id also allows for decoupling actual TCP congestion control
module management from the FIB layer, i.e. we don't have to care
about expensive module refcounting inside the FIB at this point.
We first thought of using an IDR store for the realization, which
takes over dynamic assignment of unused key space and also performs
the key to pointer mapping in RCU. While doing so, we stumbled upon
the issue that due to the nature of dynamic key distribution, it
just so happens, arguably in very rare occasions, that excessive
module loads and unloads can lead to a possible reuse of previously
used key space. Thus, previously stale keys in the dst metric are
now being reassigned to a different congestion control algorithm,
which might lead to unexpected behaviour. One way to resolve this
would have been to walk FIBs on the actually rare occasion of a
module unload and reset the metric keys for each FIB in each netns,
but that's just very costly.
Therefore, we argue a better solution is to reuse the unique
congestion control algorithm name member and map that into u32 key
space through jhash. For that, we split the flags attribute (as it
currently uses 2 bits only anyway) into two u32 attributes, flags
and key, so that we can keep the cacheline boundary of 2 cachelines
on x86_64 and cache the precalculated key at registration time for
the fast path. On average we might expect 2 - 4 modules being loaded
worst case perhaps 15, so a key collision possibility is extremely
low, and guaranteed collision-free on LE/BE for all in-tree modules.
Overall this results in much simpler code, and all without the
overhead of an IDR. Due to the deterministic nature, modules can
now be unloaded, the congestion control algorithm for a specific
but unloaded key will fall back to the default one, and on module
reload time it will switch back to the expected algorithm
transparently.
Joint work with Florian Westphal.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:46 +03:00
char * tcp_ca_get_name_by_key ( u32 key , char * buffer ) ;
2015-01-06 01:57:47 +03:00
# else
static inline char * tcp_ca_get_name_by_key ( u32 key , char * buffer )
{
return NULL ;
}
# endif
net: tcp: add key management to congestion control
This patch adds necessary infrastructure to the congestion control
framework for later per route congestion control support.
For a per route congestion control possibility, our aim is to store
a unique u32 key identifier into dst metrics, which can then be
mapped into a tcp_congestion_ops struct. We argue that having a
RTAX key entry is the most simple, generic and easy way to manage,
and also keeps the memory footprint of dst entries lower on 64 bit
than with storing a pointer directly, for example. Having a unique
key id also allows for decoupling actual TCP congestion control
module management from the FIB layer, i.e. we don't have to care
about expensive module refcounting inside the FIB at this point.
We first thought of using an IDR store for the realization, which
takes over dynamic assignment of unused key space and also performs
the key to pointer mapping in RCU. While doing so, we stumbled upon
the issue that due to the nature of dynamic key distribution, it
just so happens, arguably in very rare occasions, that excessive
module loads and unloads can lead to a possible reuse of previously
used key space. Thus, previously stale keys in the dst metric are
now being reassigned to a different congestion control algorithm,
which might lead to unexpected behaviour. One way to resolve this
would have been to walk FIBs on the actually rare occasion of a
module unload and reset the metric keys for each FIB in each netns,
but that's just very costly.
Therefore, we argue a better solution is to reuse the unique
congestion control algorithm name member and map that into u32 key
space through jhash. For that, we split the flags attribute (as it
currently uses 2 bits only anyway) into two u32 attributes, flags
and key, so that we can keep the cacheline boundary of 2 cachelines
on x86_64 and cache the precalculated key at registration time for
the fast path. On average we might expect 2 - 4 modules being loaded
worst case perhaps 15, so a key collision possibility is extremely
low, and guaranteed collision-free on LE/BE for all in-tree modules.
Overall this results in much simpler code, and all without the
overhead of an IDR. Due to the deterministic nature, modules can
now be unloaded, the congestion control algorithm for a specific
but unloaded key will fall back to the default one, and on module
reload time it will switch back to the expected algorithm
transparently.
Joint work with Florian Westphal.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-01-06 01:57:46 +03:00
2014-09-27 00:37:33 +04:00
static inline bool tcp_ca_needs_ecn ( const struct sock * sk )
{
const struct inet_connection_sock * icsk = inet_csk ( sk ) ;
return icsk - > icsk_ca_ops - > flags & TCP_CONG_NEEDS_ECN ;
}
2005-08-10 11:03:31 +04:00
static inline void tcp_set_ca_state ( struct sock * sk , const u8 ca_state )
2005-06-23 23:19:55 +04:00
{
2005-08-10 11:03:31 +04:00
struct inet_connection_sock * icsk = inet_csk ( sk ) ;
if ( icsk - > icsk_ca_ops - > set_state )
icsk - > icsk_ca_ops - > set_state ( sk , ca_state ) ;
icsk - > icsk_ca_state = ca_state ;
2005-06-23 23:19:55 +04:00
}
2005-08-10 11:03:31 +04:00
static inline void tcp_ca_event ( struct sock * sk , const enum tcp_ca_event event )
2005-06-23 23:19:55 +04:00
{
2005-08-10 11:03:31 +04:00
const struct inet_connection_sock * icsk = inet_csk ( sk ) ;
if ( icsk - > icsk_ca_ops - > cwnd_event )
icsk - > icsk_ca_ops - > cwnd_event ( sk , event ) ;
2005-06-23 23:19:55 +04:00
}
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
/* From tcp_rate.c */
void tcp_rate_skb_sent ( struct sock * sk , struct sk_buff * skb ) ;
void tcp_rate_skb_delivered ( struct sock * sk , struct sk_buff * skb ,
struct rate_sample * rs ) ;
void tcp_rate_gen ( struct sock * sk , u32 delivered , u32 lost ,
2017-12-08 00:41:34 +03:00
bool is_sack_reneg , struct rate_sample * rs ) ;
2016-09-20 06:39:15 +03:00
void tcp_rate_check_app_limited ( struct sock * sk ) ;
tcp: track data delivery rate for a TCP connection
This patch generates data delivery rate (throughput) samples on a
per-ACK basis. These rate samples can be used by congestion control
modules, and specifically will be used by TCP BBR in later patches in
this series.
Key state:
tp->delivered: Tracks the total number of data packets (original or not)
delivered so far. This is an already-existing field.
tp->delivered_mstamp: the last time tp->delivered was updated.
Algorithm:
A rate sample is calculated as (d1 - d0)/(t1 - t0) on a per-ACK basis:
d1: the current tp->delivered after processing the ACK
t1: the current time after processing the ACK
d0: the prior tp->delivered when the acked skb was transmitted
t0: the prior tp->delivered_mstamp when the acked skb was transmitted
When an skb is transmitted, we snapshot d0 and t0 in its control
block in tcp_rate_skb_sent().
When an ACK arrives, it may SACK and ACK some skbs. For each SACKed
or ACKed skb, tcp_rate_skb_delivered() updates the rate_sample struct
to reflect the latest (d0, t0).
Finally, tcp_rate_gen() generates a rate sample by storing
(d1 - d0) in rs->delivered and (t1 - t0) in rs->interval_us.
One caveat: if an skb was sent with no packets in flight, then
tp->delivered_mstamp may be either invalid (if the connection is
starting) or outdated (if the connection was idle). In that case,
we'll re-stamp tp->delivered_mstamp.
At first glance it seems t0 should always be the time when an skb was
transmitted, but actually this could over-estimate the rate due to
phase mismatch between transmit and ACK events. To track the delivery
rate, we ensure that if packets are in flight then t0 and and t1 are
times at which packets were marked delivered.
If the initial and final RTTs are different then one may be corrupted
by some sort of noise. The noise we see most often is sending gaps
caused by delayed, compressed, or stretched acks. This either affects
both RTTs equally or artificially reduces the final RTT. We approach
this by recording the info we need to compute the initial RTT
(duration of the "send phase" of the window) when we recorded the
associated inflight. Then, for a filter to avoid bandwidth
overestimates, we generalize the per-sample bandwidth computation
from:
bw = delivered / ack_phase_rtt
to the following:
bw = delivered / max(send_phase_rtt, ack_phase_rtt)
In large-scale experiments, this filtering approach incorporating
send_phase_rtt is effective at avoiding bandwidth overestimates due to
ACK compression or stretched ACKs.
Signed-off-by: Van Jacobson <vanj@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-09-20 06:39:14 +03:00
2007-08-09 16:14:46 +04:00
/* These functions determine how the current flow behaves in respect of SACK
* handling . SACK is negotiated with the peer , and therefore it can vary
* between different flows .
*
* tcp_is_sack - SACK enabled
* tcp_is_reno - No SACK
*/
static inline int tcp_is_sack ( const struct tcp_sock * tp )
{
2018-11-28 01:42:00 +03:00
return likely ( tp - > rx_opt . sack_ok ) ;
2007-08-09 16:14:46 +04:00
}
2012-05-17 03:15:34 +04:00
static inline bool tcp_is_reno ( const struct tcp_sock * tp )
2007-08-09 16:14:46 +04:00
{
return ! tcp_is_sack ( tp ) ;
}
2007-08-09 15:37:30 +04:00
static inline unsigned int tcp_left_out ( const struct tcp_sock * tp )
{
return tp - > sacked_out + tp - > lost_out ;
}
2005-04-17 02:20:36 +04:00
/* This determines how many packets are "in the network" to the best
* of our knowledge . In many cases it is conservative , but where
* detailed information is available from the receiver ( via SACK
* blocks etc . ) we can make more aggressive calculations .
*
* Use this for decisions involving congestion control , use just
* tp - > packets_out to determine if the send queue is empty or not .
*
* Read this equation as :
*
* " Packets sent once on transmission queue " MINUS
* " Packets left network, but not honestly ACKed yet " PLUS
* " Packets fast retransmitted "
*/
2006-01-04 03:03:49 +03:00
static inline unsigned int tcp_packets_in_flight ( const struct tcp_sock * tp )
2005-04-17 02:20:36 +04:00
{
2007-08-09 15:37:30 +04:00
return tp - > packets_out - tcp_left_out ( tp ) + tp - > retrans_out ;
2005-04-17 02:20:36 +04:00
}
2009-09-15 12:30:10 +04:00
# define TCP_INFINITE_SSTHRESH 0x7fffffff
2015-07-09 23:16:29 +03:00
static inline bool tcp_in_slow_start ( const struct tcp_sock * tp )
{
2015-07-09 23:16:30 +03:00
return tp - > snd_cwnd < tp - > snd_ssthresh ;
2015-07-09 23:16:29 +03:00
}
2009-09-15 12:30:10 +04:00
static inline bool tcp_in_initial_slowstart ( const struct tcp_sock * tp )
{
return tp - > snd_ssthresh > = TCP_INFINITE_SSTHRESH ;
}
2012-09-02 21:38:04 +04:00
static inline bool tcp_in_cwnd_reduction ( const struct sock * sk )
{
return ( TCPF_CA_CWR | TCPF_CA_Recovery ) &
( 1 < < inet_csk ( sk ) - > icsk_ca_state ) ;
}
2005-04-17 02:20:36 +04:00
/* If cwnd > ssthresh, we may raise ssthresh to be half-way to cwnd.
2012-09-02 21:38:04 +04:00
* The exception is cwnd reduction phase , when cwnd is decreasing towards
2005-04-17 02:20:36 +04:00
* ssthresh .
*/
2005-08-10 11:03:31 +04:00
static inline __u32 tcp_current_ssthresh ( const struct sock * sk )
2005-04-17 02:20:36 +04:00
{
2005-08-10 11:03:31 +04:00
const struct tcp_sock * tp = tcp_sk ( sk ) ;
2011-10-21 13:22:42 +04:00
2012-09-02 21:38:04 +04:00
if ( tcp_in_cwnd_reduction ( sk ) )
2005-04-17 02:20:36 +04:00
return tp - > snd_ssthresh ;
else
return max ( tp - > snd_ssthresh ,
( ( tp - > snd_cwnd > > 1 ) +
( tp - > snd_cwnd > > 2 ) ) ) ;
}
2007-07-27 17:36:17 +04:00
/* Use define here intentionally to get WARN_ON location shown at the caller */
# define tcp_verify_left_out(tp) WARN_ON(tcp_left_out(tp) > tp->packets_out)
2005-04-17 02:20:36 +04:00
2014-07-14 18:58:32 +04:00
void tcp_enter_cwr ( struct sock * sk ) ;
2013-09-23 22:33:32 +04:00
__u32 tcp_init_cwnd ( const struct tcp_sock * tp , const struct dst_entry * dst ) ;
2005-04-17 02:20:36 +04:00
2011-11-21 21:15:14 +04:00
/* The maximum number of MSS of available cwnd for which TSO defers
* sending if not using sysctl_tcp_tso_win_divisor .
*/
static inline __u32 tcp_max_tso_deferred_mss ( const struct tcp_sock * tp )
{
return 3 ;
}
2007-12-31 15:48:41 +03:00
/* Returns end sequence number of the receiver's advertised window */
static inline u32 tcp_wnd_end ( const struct tcp_sock * tp )
{
return tp - > snd_una + tp - > snd_wnd ;
}
tcp: fix cwnd limited checking to improve congestion control
Yuchung discovered tcp_is_cwnd_limited() was returning false in
slow start phase even if the application filled the socket write queue.
All congestion modules take into account tcp_is_cwnd_limited()
before increasing cwnd, so this behavior limits slow start from
probing the bandwidth at full speed.
The problem is that even if write queue is full (aka we are _not_
application limited), cwnd can be under utilized if TSO should auto
defer or TCP Small queues decided to hold packets.
So the in_flight can be kept to smaller value, and we can get to the
point tcp_is_cwnd_limited() returns false.
With TCP Small Queues and FQ/pacing, this issue is more visible.
We fix this by having tcp_cwnd_validate(), which is supposed to track
such things, take into account unsent_segs, the number of segs that we
are not sending at the moment due to TSO or TSQ, but intend to send
real soon. Then when we are cwnd-limited, remember this fact while we
are processing the window of ACKs that comes back.
For example, suppose we have a brand new connection with cwnd=10; we
are in slow start, and we send a flight of 9 packets. By the time we
have received ACKs for all 9 packets we want our cwnd to be 18.
We implement this by setting tp->lsnd_pending to 9, and
considering ourselves to be cwnd-limited while cwnd is less than
twice tp->lsnd_pending (2*9 -> 18).
This makes tcp_is_cwnd_limited() more understandable, by removing
the GSO/TSO kludge, that tried to work around the issue.
Note the in_flight parameter can be removed in a followup cleanup
patch.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-30 22:58:13 +04:00
/* We follow the spirit of RFC2861 to validate cwnd but implement a more
* flexible approach . The RFC suggests cwnd should not be raised unless
2014-05-22 18:41:08 +04:00
* it was fully used previously . And that ' s exactly what we do in
* congestion avoidance mode . But in slow start we allow cwnd to grow
* as long as the application has used half the cwnd .
tcp: fix cwnd limited checking to improve congestion control
Yuchung discovered tcp_is_cwnd_limited() was returning false in
slow start phase even if the application filled the socket write queue.
All congestion modules take into account tcp_is_cwnd_limited()
before increasing cwnd, so this behavior limits slow start from
probing the bandwidth at full speed.
The problem is that even if write queue is full (aka we are _not_
application limited), cwnd can be under utilized if TSO should auto
defer or TCP Small queues decided to hold packets.
So the in_flight can be kept to smaller value, and we can get to the
point tcp_is_cwnd_limited() returns false.
With TCP Small Queues and FQ/pacing, this issue is more visible.
We fix this by having tcp_cwnd_validate(), which is supposed to track
such things, take into account unsent_segs, the number of segs that we
are not sending at the moment due to TSO or TSQ, but intend to send
real soon. Then when we are cwnd-limited, remember this fact while we
are processing the window of ACKs that comes back.
For example, suppose we have a brand new connection with cwnd=10; we
are in slow start, and we send a flight of 9 packets. By the time we
have received ACKs for all 9 packets we want our cwnd to be 18.
We implement this by setting tp->lsnd_pending to 9, and
considering ourselves to be cwnd-limited while cwnd is less than
twice tp->lsnd_pending (2*9 -> 18).
This makes tcp_is_cwnd_limited() more understandable, by removing
the GSO/TSO kludge, that tried to work around the issue.
Note the in_flight parameter can be removed in a followup cleanup
patch.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-30 22:58:13 +04:00
* Example :
* cwnd is 10 ( IW10 ) , but application sends 9 frames .
* We allow cwnd to reach 18 when all frames are ACKed .
* This check is safe because it ' s as aggressive as slow start which already
* risks 100 % overshoot . The advantage is that we discourage application to
* either send more filler packets or data to artificially blow up the cwnd
* usage , and allow application - limited process to probe bw more aggressively .
*/
2014-05-03 08:18:05 +04:00
static inline bool tcp_is_cwnd_limited ( const struct sock * sk )
tcp: fix cwnd limited checking to improve congestion control
Yuchung discovered tcp_is_cwnd_limited() was returning false in
slow start phase even if the application filled the socket write queue.
All congestion modules take into account tcp_is_cwnd_limited()
before increasing cwnd, so this behavior limits slow start from
probing the bandwidth at full speed.
The problem is that even if write queue is full (aka we are _not_
application limited), cwnd can be under utilized if TSO should auto
defer or TCP Small queues decided to hold packets.
So the in_flight can be kept to smaller value, and we can get to the
point tcp_is_cwnd_limited() returns false.
With TCP Small Queues and FQ/pacing, this issue is more visible.
We fix this by having tcp_cwnd_validate(), which is supposed to track
such things, take into account unsent_segs, the number of segs that we
are not sending at the moment due to TSO or TSQ, but intend to send
real soon. Then when we are cwnd-limited, remember this fact while we
are processing the window of ACKs that comes back.
For example, suppose we have a brand new connection with cwnd=10; we
are in slow start, and we send a flight of 9 packets. By the time we
have received ACKs for all 9 packets we want our cwnd to be 18.
We implement this by setting tp->lsnd_pending to 9, and
considering ourselves to be cwnd-limited while cwnd is less than
twice tp->lsnd_pending (2*9 -> 18).
This makes tcp_is_cwnd_limited() more understandable, by removing
the GSO/TSO kludge, that tried to work around the issue.
Note the in_flight parameter can be removed in a followup cleanup
patch.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-30 22:58:13 +04:00
{
const struct tcp_sock * tp = tcp_sk ( sk ) ;
2014-05-22 18:41:08 +04:00
/* If in slow start, ensure cwnd grows to twice what was ACKed. */
2015-07-09 23:16:29 +03:00
if ( tcp_in_slow_start ( tp ) )
2014-05-22 18:41:08 +04:00
return tp - > snd_cwnd < 2 * tp - > max_packets_out ;
return tp - > is_cwnd_limited ;
tcp: fix cwnd limited checking to improve congestion control
Yuchung discovered tcp_is_cwnd_limited() was returning false in
slow start phase even if the application filled the socket write queue.
All congestion modules take into account tcp_is_cwnd_limited()
before increasing cwnd, so this behavior limits slow start from
probing the bandwidth at full speed.
The problem is that even if write queue is full (aka we are _not_
application limited), cwnd can be under utilized if TSO should auto
defer or TCP Small queues decided to hold packets.
So the in_flight can be kept to smaller value, and we can get to the
point tcp_is_cwnd_limited() returns false.
With TCP Small Queues and FQ/pacing, this issue is more visible.
We fix this by having tcp_cwnd_validate(), which is supposed to track
such things, take into account unsent_segs, the number of segs that we
are not sending at the moment due to TSO or TSQ, but intend to send
real soon. Then when we are cwnd-limited, remember this fact while we
are processing the window of ACKs that comes back.
For example, suppose we have a brand new connection with cwnd=10; we
are in slow start, and we send a flight of 9 packets. By the time we
have received ACKs for all 9 packets we want our cwnd to be 18.
We implement this by setting tp->lsnd_pending to 9, and
considering ourselves to be cwnd-limited while cwnd is less than
twice tp->lsnd_pending (2*9 -> 18).
This makes tcp_is_cwnd_limited() more understandable, by removing
the GSO/TSO kludge, that tried to work around the issue.
Note the in_flight parameter can be removed in a followup cleanup
patch.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-30 22:58:13 +04:00
}
2005-11-11 03:53:30 +03:00
2018-06-20 23:07:35 +03:00
/* BBR congestion control needs pacing.
* Same remark for SO_MAX_PACING_RATE .
* sch_fq packet scheduler is efficiently handling pacing ,
* but is not always installed / used .
* Return true if TCP stack should pace packets itself .
*/
static inline bool tcp_needs_internal_pacing ( const struct sock * sk )
{
return smp_load_acquire ( & sk - > sk_pacing_status ) = = SK_PACING_NEEDED ;
}
2018-10-23 21:54:16 +03:00
/* Return in jiffies the delay before one skb is sent.
* If @ skb is NULL , we look at EDT for next packet being sent on the socket .
*/
static inline unsigned long tcp_pacing_delay ( const struct sock * sk ,
const struct sk_buff * skb )
{
s64 pacing_delay = skb ? skb - > tstamp : tcp_sk ( sk ) - > tcp_wstamp_ns ;
pacing_delay - = tcp_sk ( sk ) - > tcp_clock_cache ;
return pacing_delay > 0 ? nsecs_to_jiffies ( pacing_delay ) : 0 ;
}
static inline void tcp_reset_xmit_timer ( struct sock * sk ,
const int what ,
unsigned long when ,
const unsigned long max_when ,
const struct sk_buff * skb )
{
inet_csk_reset_xmit_timer ( sk , what , when + tcp_pacing_delay ( sk , skb ) ,
max_when ) ;
}
tcp: adjust window probe timers to safer values
With the advent of small rto timers in datacenter TCP,
(ip route ... rto_min x), the following can happen :
1) Qdisc is full, transmit fails.
TCP sets a timer based on icsk_rto to retry the transmit, without
exponential backoff.
With low icsk_rto, and lot of sockets, all cpus are servicing timer
interrupts like crazy.
Intent of the code was to retry with a timer between 200 (TCP_RTO_MIN)
and 500ms (TCP_RESOURCE_PROBE_INTERVAL)
2) Receivers can send zero windows if they don't drain their receive queue.
TCP sends zero window probes, based on icsk_rto current value, with
exponential backoff.
With /proc/sys/net/ipv4/tcp_retries2 being 15 (or even smaller in
some cases), sender can abort in less than one or two minutes !
If receiver stops the sender, it obviously doesn't care of very tight
rto. Probability of dropping the ACK reopening the window is not
worth the risk.
Lets change the base timer to be at least 200ms (TCP_RTO_MIN) for these
events (but not normal RTO based retransmits)
A followup patch adds a new SNMP counter, as it would have helped a lot
diagnosing this issue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-07 00:26:24 +03:00
/* Something is really bad, we could not queue an additional packet,
2018-10-23 21:54:16 +03:00
* because qdisc is full or receiver sent a 0 window , or we are paced .
tcp: adjust window probe timers to safer values
With the advent of small rto timers in datacenter TCP,
(ip route ... rto_min x), the following can happen :
1) Qdisc is full, transmit fails.
TCP sets a timer based on icsk_rto to retry the transmit, without
exponential backoff.
With low icsk_rto, and lot of sockets, all cpus are servicing timer
interrupts like crazy.
Intent of the code was to retry with a timer between 200 (TCP_RTO_MIN)
and 500ms (TCP_RESOURCE_PROBE_INTERVAL)
2) Receivers can send zero windows if they don't drain their receive queue.
TCP sends zero window probes, based on icsk_rto current value, with
exponential backoff.
With /proc/sys/net/ipv4/tcp_retries2 being 15 (or even smaller in
some cases), sender can abort in less than one or two minutes !
If receiver stops the sender, it obviously doesn't care of very tight
rto. Probability of dropping the ACK reopening the window is not
worth the risk.
Lets change the base timer to be at least 200ms (TCP_RTO_MIN) for these
events (but not normal RTO based retransmits)
A followup patch adds a new SNMP counter, as it would have helped a lot
diagnosing this issue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-07 00:26:24 +03:00
* We do not want to add fuel to the fire , or abort too early ,
* so make sure the timer we arm now is at least 200 ms in the future ,
* regardless of current icsk_rto value ( as it could be ~ 2 ms )
*/
static inline unsigned long tcp_probe0_base ( const struct sock * sk )
2005-04-17 02:20:36 +04:00
{
tcp: adjust window probe timers to safer values
With the advent of small rto timers in datacenter TCP,
(ip route ... rto_min x), the following can happen :
1) Qdisc is full, transmit fails.
TCP sets a timer based on icsk_rto to retry the transmit, without
exponential backoff.
With low icsk_rto, and lot of sockets, all cpus are servicing timer
interrupts like crazy.
Intent of the code was to retry with a timer between 200 (TCP_RTO_MIN)
and 500ms (TCP_RESOURCE_PROBE_INTERVAL)
2) Receivers can send zero windows if they don't drain their receive queue.
TCP sends zero window probes, based on icsk_rto current value, with
exponential backoff.
With /proc/sys/net/ipv4/tcp_retries2 being 15 (or even smaller in
some cases), sender can abort in less than one or two minutes !
If receiver stops the sender, it obviously doesn't care of very tight
rto. Probability of dropping the ACK reopening the window is not
worth the risk.
Lets change the base timer to be at least 200ms (TCP_RTO_MIN) for these
events (but not normal RTO based retransmits)
A followup patch adds a new SNMP counter, as it would have helped a lot
diagnosing this issue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-07 00:26:24 +03:00
return max_t ( unsigned long , inet_csk ( sk ) - > icsk_rto , TCP_RTO_MIN ) ;
}
[TCP]: Sed magic converts func(sk, tp, ...) -> func(sk, ...)
This is (mostly) automated change using magic:
sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)|
struct sock \*sk\1\tstruct tcp_sock *tp = tcp_sk(sk);\n|g'
-e 's|struct sock \*sk, struct tcp_sock \*tp|
struct sock \*sk|g' -e 's|sk, tp\([^-]\)|sk\1|g'
Fixed four unused variable (tp) warnings that were introduced.
In addition, manually added newlines after local variables and
tweaked function arguments positioning.
$ gcc --version
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
...
$ codiff -fV built-in.o.old built-in.o.new
net/ipv4/route.c:
rt_cache_flush | +14
1 function changed, 14 bytes added
net/ipv4/tcp.c:
tcp_setsockopt | -5
tcp_sendpage | -25
tcp_sendmsg | -16
3 functions changed, 46 bytes removed
net/ipv4/tcp_input.c:
tcp_try_undo_recovery | +3
tcp_try_undo_dsack | +2
tcp_mark_head_lost | -12
tcp_ack | -15
tcp_event_data_recv | -32
tcp_rcv_state_process | -10
tcp_rcv_established | +1
7 functions changed, 6 bytes added, 69 bytes removed, diff: -63
net/ipv4/tcp_output.c:
update_send_head | -9
tcp_transmit_skb | +19
tcp_cwnd_validate | +1
tcp_write_wakeup | -17
__tcp_push_pending_frames | -25
tcp_push_one | -8
tcp_send_fin | -4
7 functions changed, 20 bytes added, 63 bytes removed, diff: -43
built-in.o.new:
18 functions changed, 40 bytes added, 178 bytes removed, diff: -138
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-21 09:18:02 +04:00
tcp: adjust window probe timers to safer values
With the advent of small rto timers in datacenter TCP,
(ip route ... rto_min x), the following can happen :
1) Qdisc is full, transmit fails.
TCP sets a timer based on icsk_rto to retry the transmit, without
exponential backoff.
With low icsk_rto, and lot of sockets, all cpus are servicing timer
interrupts like crazy.
Intent of the code was to retry with a timer between 200 (TCP_RTO_MIN)
and 500ms (TCP_RESOURCE_PROBE_INTERVAL)
2) Receivers can send zero windows if they don't drain their receive queue.
TCP sends zero window probes, based on icsk_rto current value, with
exponential backoff.
With /proc/sys/net/ipv4/tcp_retries2 being 15 (or even smaller in
some cases), sender can abort in less than one or two minutes !
If receiver stops the sender, it obviously doesn't care of very tight
rto. Probability of dropping the ACK reopening the window is not
worth the risk.
Lets change the base timer to be at least 200ms (TCP_RTO_MIN) for these
events (but not normal RTO based retransmits)
A followup patch adds a new SNMP counter, as it would have helped a lot
diagnosing this issue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-07 00:26:24 +03:00
/* Variant of inet_csk_rto_backoff() used for zero window probes */
static inline unsigned long tcp_probe0_when ( const struct sock * sk ,
unsigned long max_when )
{
u64 when = ( u64 ) tcp_probe0_base ( sk ) < < inet_csk ( sk ) - > icsk_backoff ;
return ( unsigned long ) min_t ( u64 , when , max_when ) ;
}
static inline void tcp_check_probe_timer ( struct sock * sk )
{
if ( ! tcp_sk ( sk ) - > packets_out & & ! inet_csk ( sk ) - > icsk_pending )
2018-10-23 21:54:16 +03:00
tcp_reset_xmit_timer ( sk , ICSK_TIME_PROBE0 ,
tcp_probe0_base ( sk ) , TCP_RTO_MAX ,
NULL ) ;
2005-04-17 02:20:36 +04:00
}
2009-03-03 09:42:02 +03:00
static inline void tcp_init_wl ( struct tcp_sock * tp , u32 seq )
2005-04-17 02:20:36 +04:00
{
tp - > snd_wl1 = seq ;
}
2009-03-03 09:42:02 +03:00
static inline void tcp_update_wl ( struct tcp_sock * tp , u32 seq )
2005-04-17 02:20:36 +04:00
{
tp - > snd_wl1 = seq ;
}
/*
* Calculate ( / check ) TCP checksum
*/
2007-02-05 07:15:27 +03:00
static inline __sum16 tcp_v4_check ( int len , __be32 saddr ,
__be32 daddr , __wsum base )
2005-04-17 02:20:36 +04:00
{
2019-04-20 18:50:42 +03:00
return csum_tcpudp_magic ( saddr , daddr , len , IPPROTO_TCP , base ) ;
2005-04-17 02:20:36 +04:00
}
2012-05-17 03:15:34 +04:00
static inline bool tcp_checksum_complete ( struct sk_buff * skb )
2005-04-17 02:20:36 +04:00
{
2007-04-09 22:59:39 +04:00
return ! skb_csum_unnecessary ( skb ) & &
2018-11-13 03:17:00 +03:00
__skb_checksum_complete ( skb ) ;
2005-04-17 02:20:36 +04:00
}
2016-08-27 17:37:54 +03:00
bool tcp_add_backlog ( struct sock * sk , struct sk_buff * skb ) ;
2016-11-11 00:12:35 +03:00
int tcp_filter ( struct sock * sk , struct sk_buff * skb ) ;
2013-09-23 22:33:32 +04:00
void tcp_set_state ( struct sock * sk , int state ) ;
void tcp_done ( struct sock * sk ) ;
2015-12-16 06:30:05 +03:00
int tcp_abort ( struct sock * sk , int err ) ;
2006-01-04 03:03:49 +03:00
static inline void tcp_sack_reset ( struct tcp_options_received * rx_opt )
2005-04-17 02:20:36 +04:00
{
rx_opt - > dsack = 0 ;
rx_opt - > num_sacks = 0 ;
}
2013-09-23 22:33:32 +04:00
u32 tcp_default_init_rwnd ( u32 mss ) ;
tcp: fix slow start after idle vs TSO/GSO
slow start after idle might reduce cwnd, but we perform this
after first packet was cooked and sent.
With TSO/GSO, it means that we might send a full TSO packet
even if cwnd should have been reduced to IW10.
Moving the SSAI check in skb_entail() makes sense, because
we slightly reduce number of times this check is done,
especially for large send() and TCP Small queue callbacks from
softirq context.
As Neal pointed out, we also need to perform the check
if/when receive window opens.
Tested:
Following packetdrill test demonstrates the problem
// Test of slow start after idle
`sysctl -q net.ipv4.tcp_slow_start_after_idle=1`
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 65535 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>
+.100 < . 1:1(0) ack 1 win 511
+0 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [200000], 4) = 0
+0 write(4, ..., 26000) = 26000
+0 > . 1:5001(5000) ack 1
+0 > . 5001:10001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10 }%
+.100 < . 1:1(0) ack 10001 win 511
+0 %{ assert tcpi_snd_cwnd == 20, tcpi_snd_cwnd }%
+0 > . 10001:20001(10000) ack 1
+0 > P. 20001:26001(6000) ack 1
+.100 < . 1:1(0) ack 26001 win 511
+0 %{ assert tcpi_snd_cwnd == 36, tcpi_snd_cwnd }%
+4 write(4, ..., 20000) = 20000
// If slow start after idle works properly, we should send 5 MSS here (cwnd/2)
+0 > . 26001:31001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
+0 > . 31001:36001(5000) ack 1
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-21 22:30:00 +03:00
void tcp_cwnd_restart ( struct sock * sk , s32 delta ) ;
static inline void tcp_slow_start_after_idle_check ( struct sock * sk )
{
2017-05-05 22:53:23 +03:00
const struct tcp_congestion_ops * ca_ops = inet_csk ( sk ) - > icsk_ca_ops ;
tcp: fix slow start after idle vs TSO/GSO
slow start after idle might reduce cwnd, but we perform this
after first packet was cooked and sent.
With TSO/GSO, it means that we might send a full TSO packet
even if cwnd should have been reduced to IW10.
Moving the SSAI check in skb_entail() makes sense, because
we slightly reduce number of times this check is done,
especially for large send() and TCP Small queue callbacks from
softirq context.
As Neal pointed out, we also need to perform the check
if/when receive window opens.
Tested:
Following packetdrill test demonstrates the problem
// Test of slow start after idle
`sysctl -q net.ipv4.tcp_slow_start_after_idle=1`
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 65535 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>
+.100 < . 1:1(0) ack 1 win 511
+0 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [200000], 4) = 0
+0 write(4, ..., 26000) = 26000
+0 > . 1:5001(5000) ack 1
+0 > . 5001:10001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10 }%
+.100 < . 1:1(0) ack 10001 win 511
+0 %{ assert tcpi_snd_cwnd == 20, tcpi_snd_cwnd }%
+0 > . 10001:20001(10000) ack 1
+0 > P. 20001:26001(6000) ack 1
+.100 < . 1:1(0) ack 26001 win 511
+0 %{ assert tcpi_snd_cwnd == 36, tcpi_snd_cwnd }%
+4 write(4, ..., 20000) = 20000
// If slow start after idle works properly, we should send 5 MSS here (cwnd/2)
+0 > . 26001:31001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
+0 > . 31001:36001(5000) ack 1
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-21 22:30:00 +03:00
struct tcp_sock * tp = tcp_sk ( sk ) ;
s32 delta ;
2017-10-27 07:54:59 +03:00
if ( ! sock_net ( sk ) - > ipv4 . sysctl_tcp_slow_start_after_idle | | tp - > packets_out | |
2017-05-05 22:53:23 +03:00
ca_ops - > cong_control )
tcp: fix slow start after idle vs TSO/GSO
slow start after idle might reduce cwnd, but we perform this
after first packet was cooked and sent.
With TSO/GSO, it means that we might send a full TSO packet
even if cwnd should have been reduced to IW10.
Moving the SSAI check in skb_entail() makes sense, because
we slightly reduce number of times this check is done,
especially for large send() and TCP Small queue callbacks from
softirq context.
As Neal pointed out, we also need to perform the check
if/when receive window opens.
Tested:
Following packetdrill test demonstrates the problem
// Test of slow start after idle
`sysctl -q net.ipv4.tcp_slow_start_after_idle=1`
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 65535 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>
+.100 < . 1:1(0) ack 1 win 511
+0 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [200000], 4) = 0
+0 write(4, ..., 26000) = 26000
+0 > . 1:5001(5000) ack 1
+0 > . 5001:10001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10 }%
+.100 < . 1:1(0) ack 10001 win 511
+0 %{ assert tcpi_snd_cwnd == 20, tcpi_snd_cwnd }%
+0 > . 10001:20001(10000) ack 1
+0 > P. 20001:26001(6000) ack 1
+.100 < . 1:1(0) ack 26001 win 511
+0 %{ assert tcpi_snd_cwnd == 36, tcpi_snd_cwnd }%
+4 write(4, ..., 20000) = 20000
// If slow start after idle works properly, we should send 5 MSS here (cwnd/2)
+0 > . 26001:31001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
+0 > . 31001:36001(5000) ack 1
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-21 22:30:00 +03:00
return ;
2017-05-17 00:00:03 +03:00
delta = tcp_jiffies32 - tp - > lsndtime ;
tcp: fix slow start after idle vs TSO/GSO
slow start after idle might reduce cwnd, but we perform this
after first packet was cooked and sent.
With TSO/GSO, it means that we might send a full TSO packet
even if cwnd should have been reduced to IW10.
Moving the SSAI check in skb_entail() makes sense, because
we slightly reduce number of times this check is done,
especially for large send() and TCP Small queue callbacks from
softirq context.
As Neal pointed out, we also need to perform the check
if/when receive window opens.
Tested:
Following packetdrill test demonstrates the problem
// Test of slow start after idle
`sysctl -q net.ipv4.tcp_slow_start_after_idle=1`
0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 65535 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 6>
+.100 < . 1:1(0) ack 1 win 511
+0 accept(3, ..., ...) = 4
+0 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [200000], 4) = 0
+0 write(4, ..., 26000) = 26000
+0 > . 1:5001(5000) ack 1
+0 > . 5001:10001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10 }%
+.100 < . 1:1(0) ack 10001 win 511
+0 %{ assert tcpi_snd_cwnd == 20, tcpi_snd_cwnd }%
+0 > . 10001:20001(10000) ack 1
+0 > P. 20001:26001(6000) ack 1
+.100 < . 1:1(0) ack 26001 win 511
+0 %{ assert tcpi_snd_cwnd == 36, tcpi_snd_cwnd }%
+4 write(4, ..., 20000) = 20000
// If slow start after idle works properly, we should send 5 MSS here (cwnd/2)
+0 > . 26001:31001(5000) ack 1
+0 %{ assert tcpi_snd_cwnd == 10, tcpi_snd_cwnd }%
+0 > . 31001:36001(5000) ack 1
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-08-21 22:30:00 +03:00
if ( delta > inet_csk ( sk ) - > icsk_rto )
tcp_cwnd_restart ( sk , delta ) ;
}
2013-06-12 02:35:32 +04:00
2005-04-17 02:20:36 +04:00
/* Determine a window scaling and initial window to offer. */
2017-10-27 17:47:24 +03:00
void tcp_select_initial_window ( const struct sock * sk , int __space ,
__u32 mss , __u32 * rcv_wnd ,
2013-09-23 22:33:32 +04:00
__u32 * window_clamp , int wscale_ok ,
__u8 * rcv_wscale , __u32 init_rcv_wnd ) ;
2005-04-17 02:20:36 +04:00
2017-10-27 07:55:09 +03:00
static inline int tcp_win_from_space ( const struct sock * sk , int space )
2005-04-17 02:20:36 +04:00
{
2017-10-27 07:55:09 +03:00
int tcp_adv_win_scale = sock_net ( sk ) - > ipv4 . sysctl_tcp_adv_win_scale ;
2017-03-24 02:05:12 +03:00
return tcp_adv_win_scale < = 0 ?
( space > > ( - tcp_adv_win_scale ) ) :
space - ( space > > tcp_adv_win_scale ) ;
2005-04-17 02:20:36 +04:00
}
2014-10-20 13:15:50 +04:00
/* Note: caller must be prepared to deal with negative returns */
2005-04-17 02:20:36 +04:00
static inline int tcp_space ( const struct sock * sk )
{
2019-10-11 06:17:44 +03:00
return tcp_win_from_space ( sk , READ_ONCE ( sk - > sk_rcvbuf ) -
2019-10-10 01:41:03 +03:00
READ_ONCE ( sk - > sk_backlog . len ) -
2005-04-17 02:20:36 +04:00
atomic_read ( & sk - > sk_rmem_alloc ) ) ;
2014-10-20 13:15:50 +04:00
}
2005-04-17 02:20:36 +04:00
static inline int tcp_full_space ( const struct sock * sk )
{
2019-10-11 06:17:44 +03:00
return tcp_win_from_space ( sk , READ_ONCE ( sk - > sk_rcvbuf ) ) ;
2005-04-17 02:20:36 +04:00
}
2014-05-12 07:22:11 +04:00
extern void tcp_openreq_init_rwin ( struct request_sock * req ,
2015-09-25 17:39:09 +03:00
const struct sock * sk_listener ,
const struct dst_entry * dst ) ;
2014-05-12 07:22:11 +04:00
2013-09-23 22:33:32 +04:00
void tcp_enter_memory_pressure ( struct sock * sk ) ;
2017-06-07 23:29:12 +03:00
void tcp_leave_memory_pressure ( struct sock * sk ) ;
2005-04-17 02:20:36 +04:00
static inline int keepalive_intvl_when ( const struct tcp_sock * tp )
{
2016-01-07 17:38:45 +03:00
struct net * net = sock_net ( ( struct sock * ) tp ) ;
return tp - > keepalive_intvl ? : net - > ipv4 . sysctl_tcp_keepalive_intvl ;
2005-04-17 02:20:36 +04:00
}
static inline int keepalive_time_when ( const struct tcp_sock * tp )
{
2016-01-07 17:38:43 +03:00
struct net * net = sock_net ( ( struct sock * ) tp ) ;
return tp - > keepalive_time ? : net - > ipv4 . sysctl_tcp_keepalive_time ;
2005-04-17 02:20:36 +04:00
}
2009-08-29 10:48:54 +04:00
static inline int keepalive_probes ( const struct tcp_sock * tp )
{
2016-01-07 17:38:44 +03:00
struct net * net = sock_net ( ( struct sock * ) tp ) ;
return tp - > keepalive_probes ? : net - > ipv4 . sysctl_tcp_keepalive_probes ;
2009-08-29 10:48:54 +04:00
}
2010-04-26 22:33:27 +04:00
static inline u32 keepalive_time_elapsed ( const struct tcp_sock * tp )
{
const struct inet_connection_sock * icsk = & tp - > inet_conn ;
2017-05-17 00:00:07 +03:00
return min_t ( u32 , tcp_jiffies32 - icsk - > icsk_ack . lrcvtime ,
tcp_jiffies32 - tp - > rcv_tstamp ) ;
2010-04-26 22:33:27 +04:00
}
2005-08-10 07:10:42 +04:00
static inline int tcp_fin_time ( const struct sock * sk )
2005-04-17 02:20:36 +04:00
{
2016-02-03 10:46:56 +03:00
int fin_timeout = tcp_sk ( sk ) - > linger2 ? : sock_net ( sk ) - > ipv4 . sysctl_tcp_fin_timeout ;
2005-08-10 07:10:42 +04:00
const int rto = inet_csk ( sk ) - > icsk_rto ;
2005-04-17 02:20:36 +04:00
2005-08-10 07:10:42 +04:00
if ( fin_timeout < ( rto < < 2 ) - ( rto > > 1 ) )
fin_timeout = ( rto < < 2 ) - ( rto > > 1 ) ;
2005-04-17 02:20:36 +04:00
return fin_timeout ;
}
2012-05-17 03:15:34 +04:00
static inline bool tcp_paws_check ( const struct tcp_options_received * rx_opt ,
int paws_win )
2005-04-17 02:20:36 +04:00
{
2009-03-14 17:23:03 +03:00
if ( ( s32 ) ( rx_opt - > ts_recent - rx_opt - > rcv_tsval ) < = paws_win )
2012-05-17 03:15:34 +04:00
return true ;
2018-07-11 13:16:12 +03:00
if ( unlikely ( ! time_before32 ( ktime_get_seconds ( ) ,
rx_opt - > ts_recent_stamp + TCP_PAWS_24DAYS ) ) )
2012-05-17 03:15:34 +04:00
return true ;
2010-12-17 01:08:34 +03:00
/*
* Some OSes send SYN and SYNACK messages with tsval = 0 tsecr = 0 ,
* then following tcp messages have valid values . Ignore 0 value ,
* or else ' negative ' tsval might forbid us to accept their packets .
*/
if ( ! rx_opt - > ts_recent )
2012-05-17 03:15:34 +04:00
return true ;
return false ;
2009-03-14 17:23:03 +03:00
}
2012-05-17 03:15:34 +04:00
static inline bool tcp_paws_reject ( const struct tcp_options_received * rx_opt ,
int rst )
2009-03-14 17:23:03 +03:00
{
if ( tcp_paws_check ( rx_opt , 0 ) )
2012-05-17 03:15:34 +04:00
return false ;
2005-04-17 02:20:36 +04:00
/* RST segments are not recommended to carry timestamp,
and , if they do , it is recommended to ignore PAWS because
" their cleanup function should take precedence over timestamps. "
Certainly , it is mistake . It is necessary to understand the reasons
of this constraint to relax it : if peer reboots , clock may go
out - of - sync and half - open connections will not be reset .
Actually , the problem would be not existing if all
the implementations followed draft about maintaining clock
via reboots . Linux - 2.2 DOES NOT !
However , we can relax time bounds for RST segments to MSL .
*/
2018-07-11 13:16:12 +03:00
if ( rst & & ! time_before32 ( ktime_get_seconds ( ) ,
rx_opt - > ts_recent_stamp + TCP_PAWS_MSL ) )
2012-05-17 03:15:34 +04:00
return false ;
return true ;
2005-04-17 02:20:36 +04:00
}
2015-03-17 07:06:20 +03:00
bool tcp_oow_rate_limited ( struct net * net , const struct sk_buff * skb ,
int mib_idx , u32 * last_oow_ack_time ) ;
tcp: helpers to mitigate ACK loops by rate-limiting out-of-window dupacks
Helpers for mitigating ACK loops by rate-limiting dupacks sent in
response to incoming out-of-window packets.
This patch includes:
- rate-limiting logic
- sysctl to control how often we allow dupacks to out-of-window packets
- SNMP counter for cases where we rate-limited our dupack sending
The rate-limiting logic in this patch decides to not send dupacks in
response to out-of-window segments if (a) they are SYNs or pure ACKs
and (b) the remote endpoint is sending them faster than the configured
rate limit.
We rate-limit our responses rather than blocking them entirely or
resetting the connection, because legitimate connections can rely on
dupacks in response to some out-of-window segments. For example, zero
window probes are typically sent with a sequence number that is below
the current window, and ZWPs thus expect to thus elicit a dupack in
response.
We allow dupacks in response to TCP segments with data, because these
may be spurious retransmissions for which the remote endpoint wants to
receive DSACKs. This is safe because segments with data can't
realistically be part of ACK loops, which by their nature consist of
each side sending pure/data-less ACKs to each other.
The dupack interval is controlled by a new sysctl knob,
tcp_invalid_ratelimit, given in milliseconds, in case an administrator
needs to dial this upward in the face of a high-rate DoS attack. The
name and units are chosen to be analogous to the existing analogous
knob for ICMP, icmp_ratelimit.
The default value for tcp_invalid_ratelimit is 500ms, which allows at
most one such dupack per 500ms. This is chosen to be 2x faster than
the 1-second minimum RTO interval allowed by RFC 6298 (section 2, rule
2.4). We allow the extra 2x factor because network delay variations
can cause packets sent at 1 second intervals to be compressed and
arrive much closer.
Reported-by: Avery Fay <avery@mixpanel.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-07 00:04:38 +03:00
2008-07-17 07:21:42 +04:00
static inline void tcp_mib_init ( struct net * net )
2005-04-17 02:20:36 +04:00
{
/* See RFC 2012 */
net: snmp: kill various STATS_USER() helpers
In the old days (before linux-3.0), SNMP counters were duplicated,
one for user context, and one for BH context.
After commit 8f0ea0fe3a03 ("snmp: reduce percpu needs by 50%")
we have a single copy, and what really matters is preemption being
enabled or disabled, since we use this_cpu_inc() or __this_cpu_inc()
respectively.
We therefore kill SNMP_INC_STATS_USER(), SNMP_ADD_STATS_USER(),
NET_INC_STATS_USER(), NET_ADD_STATS_USER(), SCTP_INC_STATS_USER(),
SNMP_INC_STATS64_USER(), SNMP_ADD_STATS64_USER(), TCP_ADD_STATS_USER(),
UDP_INC_STATS_USER(), UDP6_INC_STATS_USER(), and XFRM_INC_STATS_USER()
Following patches will rename __BH helpers to make clear their
usage is not tied to BH being disabled.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-28 02:44:27 +03:00
TCP_ADD_STATS ( net , TCP_MIB_RTOALGORITHM , 1 ) ;
TCP_ADD_STATS ( net , TCP_MIB_RTOMIN , TCP_RTO_MIN * 1000 / HZ ) ;
TCP_ADD_STATS ( net , TCP_MIB_RTOMAX , TCP_RTO_MAX * 1000 / HZ ) ;
TCP_ADD_STATS ( net , TCP_MIB_MAXCONN , - 1 ) ;
2005-04-17 02:20:36 +04:00
}
2007-09-20 22:30:48 +04:00
/* from STCP */
2008-09-21 08:25:15 +04:00
static inline void tcp_clear_retrans_hints_partial ( struct tcp_sock * tp )
2007-09-20 22:40:37 +04:00
{
2005-11-11 04:14:59 +03:00
tp - > lost_skb_hint = NULL ;
2008-09-21 08:25:15 +04:00
}
static inline void tcp_clear_all_retrans_hints ( struct tcp_sock * tp )
{
tcp_clear_retrans_hints_partial ( tp ) ;
2005-11-11 04:14:59 +03:00
tp - > retransmit_skb_hint = NULL ;
2007-09-20 22:37:19 +04:00
}
2012-01-31 09:18:33 +04:00
union tcp_md5_addr {
struct in_addr a4 ;
# if IS_ENABLED(CONFIG_IPV6)
struct in6_addr a6 ;
# endif
} ;
2006-11-15 06:07:45 +03:00
/* - key database */
struct tcp_md5sig_key {
2012-01-31 09:18:33 +04:00
struct hlist_node node ;
2006-11-15 06:07:45 +03:00
u8 keylen ;
2012-01-31 09:18:33 +04:00
u8 family ; /* AF_INET or AF_INET6 */
2017-06-16 04:07:06 +03:00
u8 prefixlen ;
2019-12-31 01:14:28 +03:00
union tcp_md5_addr addr ;
int l3index ; /* set if key added with L3 scope */
2012-01-31 09:18:33 +04:00
u8 key [ TCP_MD5SIG_MAXKEYLEN ] ;
struct rcu_head rcu ;
2006-11-15 06:07:45 +03:00
} ;
/* - sock block */
struct tcp_md5sig_info {
2012-01-31 09:18:33 +04:00
struct hlist_head head ;
2012-01-31 22:45:40 +04:00
struct rcu_head rcu ;
2006-11-15 06:07:45 +03:00
} ;
/* - pseudo header */
struct tcp4_pseudohdr {
__be32 saddr ;
__be32 daddr ;
__u8 pad ;
__u8 protocol ;
__be16 len ;
} ;
struct tcp6_pseudohdr {
struct in6_addr saddr ;
struct in6_addr daddr ;
__be32 len ;
__be32 protocol ; /* including padding */
} ;
union tcp_md5sum_block {
struct tcp4_pseudohdr ip4 ;
2011-12-10 13:48:31 +04:00
# if IS_ENABLED(CONFIG_IPV6)
2006-11-15 06:07:45 +03:00
struct tcp6_pseudohdr ip6 ;
# endif
} ;
/* - pool: digest algorithm, hash description and scratch buffer */
struct tcp_md5sig_pool {
2016-01-24 16:20:23 +03:00
struct ahash_request * md5_req ;
2016-06-27 19:51:53 +03:00
void * scratch ;
2006-11-15 06:07:45 +03:00
} ;
/* - functions */
2015-03-25 01:58:55 +03:00
int tcp_v4_md5_hash_skb ( char * md5_hash , const struct tcp_md5sig_key * key ,
const struct sock * sk , const struct sk_buff * skb ) ;
2013-09-23 22:33:32 +04:00
int tcp_md5_do_add ( struct sock * sk , const union tcp_md5_addr * addr ,
2019-12-31 01:14:28 +03:00
int family , u8 prefixlen , int l3index ,
const u8 * newkey , u8 newkeylen , gfp_t gfp ) ;
2013-09-23 22:33:32 +04:00
int tcp_md5_do_del ( struct sock * sk , const union tcp_md5_addr * addr ,
2019-12-31 01:14:28 +03:00
int family , u8 prefixlen , int l3index ) ;
2015-09-25 17:39:15 +03:00
struct tcp_md5sig_key * tcp_v4_md5_lookup ( const struct sock * sk ,
2015-03-25 01:58:56 +03:00
const struct sock * addr_sk ) ;
2006-11-15 06:07:45 +03:00
2008-04-18 07:45:16 +04:00
# ifdef CONFIG_TCP_MD5SIG
2018-11-28 02:03:21 +03:00
# include <linux/jump_label.h>
2019-02-26 20:49:11 +03:00
extern struct static_key_false tcp_md5_needed ;
2019-12-31 01:14:28 +03:00
struct tcp_md5sig_key * __tcp_md5_do_lookup ( const struct sock * sk , int l3index ,
2018-11-28 02:03:21 +03:00
const union tcp_md5_addr * addr ,
int family ) ;
static inline struct tcp_md5sig_key *
2019-12-31 01:14:28 +03:00
tcp_md5_do_lookup ( const struct sock * sk , int l3index ,
const union tcp_md5_addr * addr , int family )
2018-11-28 02:03:21 +03:00
{
2019-02-26 20:49:11 +03:00
if ( ! static_branch_unlikely ( & tcp_md5_needed ) )
2018-11-28 02:03:21 +03:00
return NULL ;
2019-12-31 01:14:28 +03:00
return __tcp_md5_do_lookup ( sk , l3index , addr , family ) ;
2018-11-28 02:03:21 +03:00
}
2012-01-31 09:18:33 +04:00
# define tcp_twsk_md5_key(twsk) ((twsk)->tw_md5_key)
2008-04-18 07:45:16 +04:00
# else
2019-12-31 01:14:28 +03:00
static inline struct tcp_md5sig_key *
tcp_md5_do_lookup ( const struct sock * sk , int l3index ,
const union tcp_md5_addr * addr , int family )
2012-01-31 09:18:33 +04:00
{
return NULL ;
}
2008-04-18 07:45:16 +04:00
# define tcp_twsk_md5_key(twsk) NULL
# endif
2013-09-23 22:33:32 +04:00
bool tcp_alloc_md5sig_pool ( void ) ;
2006-11-15 06:07:45 +03:00
2013-09-23 22:33:32 +04:00
struct tcp_md5sig_pool * tcp_get_md5sig_pool ( void ) ;
2013-05-20 10:52:26 +04:00
static inline void tcp_put_md5sig_pool ( void )
{
local_bh_enable ( ) ;
}
2010-05-16 11:34:04 +04:00
2013-09-23 22:33:32 +04:00
int tcp_md5_hash_skb_data ( struct tcp_md5sig_pool * , const struct sk_buff * ,
unsigned int header_len ) ;
int tcp_md5_hash_key ( struct tcp_md5sig_pool * hp ,
const struct tcp_md5sig_key * key ) ;
2006-11-15 06:07:45 +03:00
2012-08-31 16:29:11 +04:00
/* From tcp_fastopen.c */
2013-09-23 22:33:32 +04:00
void tcp_fastopen_cache_get ( struct sock * sk , u16 * mss ,
2017-12-13 00:10:40 +03:00
struct tcp_fastopen_cookie * cookie ) ;
2013-09-23 22:33:32 +04:00
void tcp_fastopen_cache_set ( struct sock * sk , u16 mss ,
2015-04-07 00:37:27 +03:00
struct tcp_fastopen_cookie * cookie , bool syn_lost ,
u16 try_exp ) ;
2012-07-19 10:43:07 +04:00
struct tcp_fastopen_request {
/* Fast Open cookie. Size 0 means a cookie request */
struct tcp_fastopen_cookie cookie ;
struct msghdr * data ; /* data in MSG_FASTOPEN */
2014-02-20 22:09:18 +04:00
size_t size ;
int copied ; /* queued in tcp_connect() */
2019-01-25 19:17:23 +03:00
struct ubuf_info * uarg ;
2012-07-19 10:43:07 +04:00
} ;
void tcp_free_fastopen_req ( struct tcp_sock * tp ) ;
2017-10-18 21:22:51 +03:00
void tcp_fastopen_destroy_cipher ( struct sock * sk ) ;
2017-09-27 06:35:42 +03:00
void tcp_fastopen_ctx_destroy ( struct net * net ) ;
2017-10-18 21:22:51 +03:00
int tcp_fastopen_reset_cipher ( struct net * net , struct sock * sk ,
2019-06-20 00:46:28 +03:00
void * primary_key , void * backup_key ) ;
2016-02-02 08:03:07 +03:00
void tcp_fastopen_add_skb ( struct sock * sk , struct sk_buff * skb ) ;
2015-09-25 03:16:05 +03:00
struct sock * tcp_try_fastopen ( struct sock * sk , struct sk_buff * skb ,
struct request_sock * req ,
2017-10-23 23:22:23 +03:00
struct tcp_fastopen_cookie * foc ,
const struct dst_entry * dst ) ;
2017-09-27 06:35:42 +03:00
void tcp_fastopen_init_key_once ( struct net * net ) ;
2017-01-23 21:59:20 +03:00
bool tcp_fastopen_cookie_check ( struct sock * sk , u16 * mss ,
struct tcp_fastopen_cookie * cookie ) ;
net/tcp-fastopen: Add new API support
This patch adds a new socket option, TCP_FASTOPEN_CONNECT, as an
alternative way to perform Fast Open on the active side (client). Prior
to this patch, a client needs to replace the connect() call with
sendto(MSG_FASTOPEN). This can be cumbersome for applications who want
to use Fast Open: these socket operations are often done in lower layer
libraries used by many other applications. Changing these libraries
and/or the socket call sequences are not trivial. A more convenient
approach is to perform Fast Open by simply enabling a socket option when
the socket is created w/o changing other socket calls sequence:
s = socket()
create a new socket
setsockopt(s, IPPROTO_TCP, TCP_FASTOPEN_CONNECT …);
newly introduced sockopt
If set, new functionality described below will be used.
Return ENOTSUPP if TFO is not supported or not enabled in the
kernel.
connect()
With cookie present, return 0 immediately.
With no cookie, initiate 3WHS with TFO cookie-request option and
return -1 with errno = EINPROGRESS.
write()/sendmsg()
With cookie present, send out SYN with data and return the number of
bytes buffered.
With no cookie, and 3WHS not yet completed, return -1 with errno =
EINPROGRESS.
No MSG_FASTOPEN flag is needed.
read()
Return -1 with errno = EWOULDBLOCK/EAGAIN if connect() is called but
write() is not called yet.
Return -1 with errno = EWOULDBLOCK/EAGAIN if connection is
established but no msg is received yet.
Return number of bytes read if socket is established and there is
msg received.
The new API simplifies life for applications that always perform a write()
immediately after a successful connect(). Such applications can now take
advantage of Fast Open by merely making one new setsockopt() call at the time
of creating the socket. Nothing else about the application's socket call
sequence needs to change.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-01-23 21:59:22 +03:00
bool tcp_fastopen_defer_connect ( struct sock * sk , int * err ) ;
2019-06-20 00:46:28 +03:00
# define TCP_FASTOPEN_KEY_LENGTH sizeof(siphash_key_t)
2019-05-29 19:33:57 +03:00
# define TCP_FASTOPEN_KEY_MAX 2
# define TCP_FASTOPEN_KEY_BUF_LENGTH \
( TCP_FASTOPEN_KEY_LENGTH * TCP_FASTOPEN_KEY_MAX )
2012-08-31 16:29:11 +04:00
/* Fastopen key context */
struct tcp_fastopen_context {
2019-06-20 00:46:28 +03:00
siphash_key_t key [ TCP_FASTOPEN_KEY_MAX ] ;
net: ipv4: move tcp_fastopen server side code to SipHash library
Using a bare block cipher in non-crypto code is almost always a bad idea,
not only for security reasons (and we've seen some examples of this in
the kernel in the past), but also for performance reasons.
In the TCP fastopen case, we call into the bare AES block cipher one or
two times (depending on whether the connection is IPv4 or IPv6). On most
systems, this results in a call chain such as
crypto_cipher_encrypt_one(ctx, dst, src)
crypto_cipher_crt(tfm)->cit_encrypt_one(crypto_cipher_tfm(tfm), ...);
aesni_encrypt
kernel_fpu_begin();
aesni_enc(ctx, dst, src); // asm routine
kernel_fpu_end();
It is highly unlikely that the use of special AES instructions has a
benefit in this case, especially since we are doing the above twice
for IPv6 connections, instead of using a transform which can process
the entire input in one go.
We could switch to the cbcmac(aes) shash, which would at least get
rid of the duplicated overhead in *some* cases (i.e., today, only
arm64 has an accelerated implementation of cbcmac(aes), while x86 will
end up using the generic cbcmac template wrapping the AES-NI cipher,
which basically ends up doing exactly the above). However, in the given
context, it makes more sense to use a light-weight MAC algorithm that
is more suitable for the purpose at hand, such as SipHash.
Since the output size of SipHash already matches our chosen value for
TCP_FASTOPEN_COOKIE_SIZE, and given that it accepts arbitrary input
sizes, this greatly simplifies the code as well.
NOTE: Server farms backing a single server IP for load balancing purposes
and sharing a single fastopen key will be adversely affected by
this change unless all systems in the pool receive their kernel
upgrades at the same time.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-17 11:09:33 +03:00
int num ;
struct rcu_head rcu ;
2012-08-31 16:29:11 +04:00
} ;
net/tcp_fastopen: Disable active side TFO in certain scenarios
Middlebox firewall issues can potentially cause server's data being
blackholed after a successful 3WHS using TFO. Following are the related
reports from Apple:
https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf
Slide 31 identifies an issue where the client ACK to the server's data
sent during a TFO'd handshake is dropped.
C ---> syn-data ---> S
C <--- syn/ack ----- S
C (accept & write)
C <---- data ------- S
C ----- ACK -> X S
[retry and timeout]
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
Slide 5 shows a similar situation that the server's data gets dropped
after 3WHS.
C ---- syn-data ---> S
C <--- syn/ack ----- S
C ---- ack --------> S
S (accept & write)
C? X <- data ------ S
[retry and timeout]
This is the worst failure b/c the client can not detect such behavior to
mitigate the situation (such as disabling TFO). Failing to proceed, the
application (e.g., SSL library) may simply timeout and retry with TFO
again, and the process repeats indefinitely.
The proposed solution is to disable active TFO globally under the
following circumstances:
1. client side TFO socket detects out of order FIN
2. client side TFO socket receives out of order RST
We disable active side TFO globally for 1hr at first. Then if it
happens again, we disable it for 2h, then 4h, 8h, ...
And we reset the timeout to 1hr if a client side TFO sockets not opened
on loopback has successfully received data segs from server.
And we examine this condition during close().
The rational behind it is that when such firewall issue happens,
application running on the client should eventually close the socket as
it is not able to get the data it is expecting. Or application running
on the server should close the socket as it is not able to receive any
response from client.
In both cases, out of order FIN or RST will get received on the client
given that the firewall will not block them as no data are in those
frames.
And we want to disable active TFO globally as it helps if the middle box
is very close to the client and most of the connections are likely to
fail.
Also, add a debug sysctl:
tcp_fastopen_blackhole_detect_timeout_sec:
the initial timeout to use when firewall blackhole issue happens.
This can be set and read.
When setting it to 0, it means to disable the active disable logic.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-21 00:45:46 +03:00
extern unsigned int sysctl_tcp_fastopen_blackhole_timeout ;
2017-04-21 00:45:47 +03:00
void tcp_fastopen_active_disable ( struct sock * sk ) ;
net/tcp_fastopen: Disable active side TFO in certain scenarios
Middlebox firewall issues can potentially cause server's data being
blackholed after a successful 3WHS using TFO. Following are the related
reports from Apple:
https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf
Slide 31 identifies an issue where the client ACK to the server's data
sent during a TFO'd handshake is dropped.
C ---> syn-data ---> S
C <--- syn/ack ----- S
C (accept & write)
C <---- data ------- S
C ----- ACK -> X S
[retry and timeout]
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
Slide 5 shows a similar situation that the server's data gets dropped
after 3WHS.
C ---- syn-data ---> S
C <--- syn/ack ----- S
C ---- ack --------> S
S (accept & write)
C? X <- data ------ S
[retry and timeout]
This is the worst failure b/c the client can not detect such behavior to
mitigate the situation (such as disabling TFO). Failing to proceed, the
application (e.g., SSL library) may simply timeout and retry with TFO
again, and the process repeats indefinitely.
The proposed solution is to disable active TFO globally under the
following circumstances:
1. client side TFO socket detects out of order FIN
2. client side TFO socket receives out of order RST
We disable active side TFO globally for 1hr at first. Then if it
happens again, we disable it for 2h, then 4h, 8h, ...
And we reset the timeout to 1hr if a client side TFO sockets not opened
on loopback has successfully received data segs from server.
And we examine this condition during close().
The rational behind it is that when such firewall issue happens,
application running on the client should eventually close the socket as
it is not able to get the data it is expecting. Or application running
on the server should close the socket as it is not able to receive any
response from client.
In both cases, out of order FIN or RST will get received on the client
given that the firewall will not block them as no data are in those
frames.
And we want to disable active TFO globally as it helps if the middle box
is very close to the client and most of the connections are likely to
fail.
Also, add a debug sysctl:
tcp_fastopen_blackhole_detect_timeout_sec:
the initial timeout to use when firewall blackhole issue happens.
This can be set and read.
When setting it to 0, it means to disable the active disable logic.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-21 00:45:46 +03:00
bool tcp_fastopen_active_should_disable ( struct sock * sk ) ;
void tcp_fastopen_active_disable_ofo_check ( struct sock * sk ) ;
2017-12-13 00:10:40 +03:00
void tcp_fastopen_active_detect_blackhole ( struct sock * sk , bool expired ) ;
net/tcp_fastopen: Disable active side TFO in certain scenarios
Middlebox firewall issues can potentially cause server's data being
blackholed after a successful 3WHS using TFO. Following are the related
reports from Apple:
https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf
Slide 31 identifies an issue where the client ACK to the server's data
sent during a TFO'd handshake is dropped.
C ---> syn-data ---> S
C <--- syn/ack ----- S
C (accept & write)
C <---- data ------- S
C ----- ACK -> X S
[retry and timeout]
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
Slide 5 shows a similar situation that the server's data gets dropped
after 3WHS.
C ---- syn-data ---> S
C <--- syn/ack ----- S
C ---- ack --------> S
S (accept & write)
C? X <- data ------ S
[retry and timeout]
This is the worst failure b/c the client can not detect such behavior to
mitigate the situation (such as disabling TFO). Failing to proceed, the
application (e.g., SSL library) may simply timeout and retry with TFO
again, and the process repeats indefinitely.
The proposed solution is to disable active TFO globally under the
following circumstances:
1. client side TFO socket detects out of order FIN
2. client side TFO socket receives out of order RST
We disable active side TFO globally for 1hr at first. Then if it
happens again, we disable it for 2h, then 4h, 8h, ...
And we reset the timeout to 1hr if a client side TFO sockets not opened
on loopback has successfully received data segs from server.
And we examine this condition during close().
The rational behind it is that when such firewall issue happens,
application running on the client should eventually close the socket as
it is not able to get the data it is expecting. Or application running
on the server should close the socket as it is not able to receive any
response from client.
In both cases, out of order FIN or RST will get received on the client
given that the firewall will not block them as no data are in those
frames.
And we want to disable active TFO globally as it helps if the middle box
is very close to the client and most of the connections are likely to
fail.
Also, add a debug sysctl:
tcp_fastopen_blackhole_detect_timeout_sec:
the initial timeout to use when firewall blackhole issue happens.
This can be set and read.
When setting it to 0, it means to disable the active disable logic.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-04-21 00:45:46 +03:00
2019-05-29 19:33:57 +03:00
/* Caller needs to wrap with rcu_read_(un)lock() */
static inline
struct tcp_fastopen_context * tcp_fastopen_get_ctx ( const struct sock * sk )
{
struct tcp_fastopen_context * ctx ;
ctx = rcu_dereference ( inet_csk ( sk ) - > icsk_accept_queue . fastopenq . ctx ) ;
if ( ! ctx )
ctx = rcu_dereference ( sock_net ( sk ) - > ipv4 . tcp_fastopen_ctx ) ;
return ctx ;
}
static inline
bool tcp_fastopen_cookie_match ( const struct tcp_fastopen_cookie * foc ,
const struct tcp_fastopen_cookie * orig )
{
if ( orig - > len = = TCP_FASTOPEN_COOKIE_SIZE & &
orig - > len = = foc - > len & &
! memcmp ( orig - > val , foc - > val , foc - > len ) )
return true ;
return false ;
}
static inline
int tcp_fastopen_context_len ( const struct tcp_fastopen_context * ctx )
{
net: ipv4: move tcp_fastopen server side code to SipHash library
Using a bare block cipher in non-crypto code is almost always a bad idea,
not only for security reasons (and we've seen some examples of this in
the kernel in the past), but also for performance reasons.
In the TCP fastopen case, we call into the bare AES block cipher one or
two times (depending on whether the connection is IPv4 or IPv6). On most
systems, this results in a call chain such as
crypto_cipher_encrypt_one(ctx, dst, src)
crypto_cipher_crt(tfm)->cit_encrypt_one(crypto_cipher_tfm(tfm), ...);
aesni_encrypt
kernel_fpu_begin();
aesni_enc(ctx, dst, src); // asm routine
kernel_fpu_end();
It is highly unlikely that the use of special AES instructions has a
benefit in this case, especially since we are doing the above twice
for IPv6 connections, instead of using a transform which can process
the entire input in one go.
We could switch to the cbcmac(aes) shash, which would at least get
rid of the duplicated overhead in *some* cases (i.e., today, only
arm64 has an accelerated implementation of cbcmac(aes), while x86 will
end up using the generic cbcmac template wrapping the AES-NI cipher,
which basically ends up doing exactly the above). However, in the given
context, it makes more sense to use a light-weight MAC algorithm that
is more suitable for the purpose at hand, such as SipHash.
Since the output size of SipHash already matches our chosen value for
TCP_FASTOPEN_COOKIE_SIZE, and given that it accepts arbitrary input
sizes, this greatly simplifies the code as well.
NOTE: Server farms backing a single server IP for load balancing purposes
and sharing a single fastopen key will be adversely affected by
this change unless all systems in the pool receive their kernel
upgrades at the same time.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-17 11:09:33 +03:00
return ctx - > num ;
2019-05-29 19:33:57 +03:00
}
2016-11-28 10:07:13 +03:00
/* Latencies incurred by various limits for a sender. They are
* chronograph - like stats that are mutually exclusive .
*/
enum tcp_chrono {
TCP_CHRONO_UNSPEC ,
TCP_CHRONO_BUSY , /* Actively sending data (non-empty write queue) */
TCP_CHRONO_RWND_LIMITED , /* Stalled by insufficient receive window */
TCP_CHRONO_SNDBUF_LIMITED , /* Stalled by insufficient send buffer */
__TCP_CHRONO_MAX ,
} ;
void tcp_chrono_start ( struct sock * sk , const enum tcp_chrono type ) ;
void tcp_chrono_stop ( struct sock * sk , const enum tcp_chrono type ) ;
2017-10-04 22:59:58 +03:00
/* This helper is needed, because skb->tcp_tsorted_anchor uses
* the same memory storage than skb - > destructor / _skb_refdst
*/
static inline void tcp_skb_tsorted_anchor_cleanup ( struct sk_buff * skb )
{
skb - > destructor = NULL ;
skb - > _skb_refdst = 0UL ;
}
# define tcp_skb_tsorted_save(skb) { \
unsigned long _save = skb - > _skb_refdst ; \
skb - > _skb_refdst = 0UL ;
# define tcp_skb_tsorted_restore(skb) \
skb - > _skb_refdst = _save ; \
}
2017-10-06 08:21:22 +03:00
void tcp_write_queue_purge ( struct sock * sk ) ;
2007-03-07 23:12:44 +03:00
2017-10-06 08:21:27 +03:00
static inline struct sk_buff * tcp_rtx_queue_head ( const struct sock * sk )
{
return skb_rb_first ( & sk - > tcp_rtx_queue ) ;
}
2019-07-19 21:52:33 +03:00
static inline struct sk_buff * tcp_rtx_queue_tail ( const struct sock * sk )
{
return skb_rb_last ( & sk - > tcp_rtx_queue ) ;
}
2011-10-21 13:22:42 +04:00
static inline struct sk_buff * tcp_write_queue_head ( const struct sock * sk )
2007-03-07 23:12:44 +03:00
{
2008-09-23 11:50:13 +04:00
return skb_peek ( & sk - > sk_write_queue ) ;
2007-03-07 23:12:44 +03:00
}
2011-10-21 13:22:42 +04:00
static inline struct sk_buff * tcp_write_queue_tail ( const struct sock * sk )
2007-03-07 23:12:44 +03:00
{
2008-09-23 11:50:13 +04:00
return skb_peek_tail ( & sk - > sk_write_queue ) ;
2007-03-07 23:12:44 +03:00
}
2007-12-02 01:48:02 +03:00
# define tcp_for_write_queue_from_safe(skb, tmp, sk) \
2008-09-23 11:50:13 +04:00
skb_queue_walk_from_safe ( & ( sk ) - > sk_write_queue , skb , tmp )
2007-12-02 01:48:02 +03:00
2011-10-21 13:22:42 +04:00
static inline struct sk_buff * tcp_send_head ( const struct sock * sk )
2007-03-07 23:12:44 +03:00
{
2017-10-06 08:21:27 +03:00
return skb_peek ( & sk - > sk_write_queue ) ;
2007-03-07 23:12:44 +03:00
}
2008-09-23 11:50:13 +04:00
static inline bool tcp_skb_is_last ( const struct sock * sk ,
const struct sk_buff * skb )
{
return skb_queue_is_last ( & sk - > sk_write_queue , skb ) ;
}
2019-12-12 23:55:30 +03:00
/**
* tcp_write_queue_empty - test if any payload ( or FIN ) is available in write queue
* @ sk : socket
*
* Since the write queue can have a temporary empty skb in it ,
* we must not use " return skb_queue_empty(&sk->sk_write_queue) "
*/
2017-10-06 08:21:27 +03:00
static inline bool tcp_write_queue_empty ( const struct sock * sk )
2007-03-07 23:12:44 +03:00
{
2019-12-12 23:55:30 +03:00
const struct tcp_sock * tp = tcp_sk ( sk ) ;
return tp - > write_seq = = tp - > snd_nxt ;
2017-10-06 08:21:27 +03:00
}
static inline bool tcp_rtx_queue_empty ( const struct sock * sk )
{
return RB_EMPTY_ROOT ( & sk - > tcp_rtx_queue ) ;
}
static inline bool tcp_rtx_and_write_queues_empty ( const struct sock * sk )
{
return tcp_rtx_queue_empty ( sk ) & & tcp_write_queue_empty ( sk ) ;
2007-03-07 23:12:44 +03:00
}
static inline void tcp_add_write_queue_tail ( struct sock * sk , struct sk_buff * skb )
{
2019-02-26 20:49:10 +03:00
__skb_queue_tail ( & sk - > sk_write_queue , skb ) ;
2007-03-07 23:12:44 +03:00
/* Queue it, remembering where we must start sending. */
2017-11-15 08:02:19 +03:00
if ( sk - > sk_write_queue . next = = skb )
2016-11-28 10:07:14 +03:00
tcp_chrono_start ( sk , TCP_CHRONO_BUSY ) ;
2007-03-07 23:12:44 +03:00
}
2008-09-22 08:28:51 +04:00
/* Insert new before skb on the write queue of sk. */
2007-03-07 23:12:44 +03:00
static inline void tcp_insert_write_queue_before ( struct sk_buff * new ,
struct sk_buff * skb ,
struct sock * sk )
{
2008-09-22 08:28:51 +04:00
__skb_queue_before ( & sk - > sk_write_queue , skb , new ) ;
2007-03-07 23:12:44 +03:00
}
static inline void tcp_unlink_write_queue ( struct sk_buff * skb , struct sock * sk )
{
2017-10-11 23:27:29 +03:00
tcp_skb_tsorted_anchor_cleanup ( skb ) ;
2007-03-07 23:12:44 +03:00
__skb_unlink ( skb , & sk - > sk_write_queue ) ;
}
2017-10-06 08:21:27 +03:00
void tcp_rbtree_insert ( struct rb_root * root , struct sk_buff * skb ) ;
static inline void tcp_rtx_queue_unlink ( struct sk_buff * skb , struct sock * sk )
2007-03-07 23:12:44 +03:00
{
2017-10-06 08:21:27 +03:00
tcp_skb_tsorted_anchor_cleanup ( skb ) ;
rb_erase ( & skb - > rbnode , & sk - > tcp_rtx_queue ) ;
}
static inline void tcp_rtx_queue_unlink_and_free ( struct sk_buff * skb , struct sock * sk )
{
list_del ( & skb - > tcp_tsorted_anchor ) ;
tcp_rtx_queue_unlink ( skb , sk ) ;
sk_wmem_free_skb ( sk , skb ) ;
2007-03-07 23:12:44 +03:00
}
2009-12-09 01:26:13 +03:00
static inline void tcp_push_pending_frames ( struct sock * sk )
{
if ( tcp_send_head ( sk ) ) {
struct tcp_sock * tp = tcp_sk ( sk ) ;
__tcp_push_pending_frames ( sk , tcp_current_mss ( sk ) , tp - > nonagle ) ;
}
}
2012-02-28 02:52:52 +04:00
/* Start sequence of the skb just after the highest skb with SACKed
* bit , valid only if sacked_out > 0 or when the caller has ensured
* validity by itself .
2007-11-16 06:41:46 +03:00
*/
static inline u32 tcp_highest_sack_seq ( struct tcp_sock * tp )
{
if ( ! tp - > sacked_out )
return tp - > snd_una ;
2007-12-02 01:48:06 +03:00
if ( tp - > highest_sack = = NULL )
return tp - > snd_nxt ;
2007-11-16 06:41:46 +03:00
return TCP_SKB_CB ( tp - > highest_sack ) - > seq ;
}
2007-12-02 01:48:06 +03:00
static inline void tcp_advance_highest_sack ( struct sock * sk , struct sk_buff * skb )
{
2017-11-15 08:02:19 +03:00
tcp_sk ( sk ) - > highest_sack = skb_rb_next ( skb ) ;
2007-12-02 01:48:06 +03:00
}
static inline struct sk_buff * tcp_highest_sack ( struct sock * sk )
{
return tcp_sk ( sk ) - > highest_sack ;
}
static inline void tcp_highest_sack_reset ( struct sock * sk )
{
2017-11-15 08:02:19 +03:00
tcp_sk ( sk ) - > highest_sack = tcp_rtx_queue_head ( sk ) ;
2007-12-02 01:48:06 +03:00
}
2017-10-31 09:08:20 +03:00
/* Called when old skb is about to be deleted and replaced by new skb */
static inline void tcp_highest_sack_replace ( struct sock * sk ,
2007-12-02 01:48:06 +03:00
struct sk_buff * old ,
struct sk_buff * new )
{
2017-10-31 09:08:20 +03:00
if ( old = = tcp_highest_sack ( sk ) )
2007-12-02 01:48:06 +03:00
tcp_sk ( sk ) - > highest_sack = new ;
}
2015-12-21 23:29:24 +03:00
/* This helper checks if socket has IP_TRANSPARENT set */
static inline bool inet_sk_transparent ( const struct sock * sk )
{
switch ( sk - > sk_state ) {
case TCP_TIME_WAIT :
return inet_twsk ( sk ) - > tw_transparent ;
case TCP_NEW_SYN_RECV :
return inet_rsk ( inet_reqsk ( sk ) ) - > no_srccheck ;
}
return inet_sk ( sk ) - > transparent ;
}
2010-02-18 05:45:45 +03:00
/* Determines whether this is a thin stream (which may suffer from
* increased latency ) . Used to trigger latency - reducing mechanisms .
*/
2012-05-17 03:15:34 +04:00
static inline bool tcp_stream_is_thin ( struct tcp_sock * tp )
2010-02-18 05:45:45 +03:00
{
return tp - > packets_out < 4 & & ! tcp_in_initial_slowstart ( tp ) ;
}
2005-04-17 02:20:36 +04:00
/* /proc */
enum tcp_seq_states {
TCP_SEQ_STATE_LISTENING ,
TCP_SEQ_STATE_ESTABLISHED ,
} ;
2018-04-11 10:31:28 +03:00
void * tcp_seq_start ( struct seq_file * seq , loff_t * pos ) ;
void * tcp_seq_next ( struct seq_file * seq , void * v , loff_t * pos ) ;
void tcp_seq_stop ( struct seq_file * seq , void * v ) ;
2011-10-30 10:46:30 +04:00
2005-04-17 02:20:36 +04:00
struct tcp_seq_afinfo {
2011-10-30 10:46:30 +04:00
sa_family_t family ;
2005-04-17 02:20:36 +04:00
} ;
struct tcp_iter_state {
2008-04-14 09:11:14 +04:00
struct seq_net_private p ;
2005-04-17 02:20:36 +04:00
enum tcp_seq_states state ;
struct sock * syn_wait_sk ;
2012-05-24 11:10:10 +04:00
int bucket , offset , sbucket , num ;
2010-06-07 11:43:42 +04:00
loff_t last_pos ;
2005-04-17 02:20:36 +04:00
} ;
2005-08-16 09:18:02 +04:00
extern struct request_sock_ops tcp_request_sock_ops ;
2008-02-08 08:49:26 +03:00
extern struct request_sock_ops tcp6_request_sock_ops ;
2005-08-16 09:18:02 +04:00
2013-09-23 22:33:32 +04:00
void tcp_v4_destroy_sock ( struct sock * sk ) ;
2005-08-16 09:18:02 +04:00
2013-10-18 21:36:17 +04:00
struct sk_buff * tcp_gso_segment ( struct sk_buff * skb ,
2013-09-23 22:33:32 +04:00
netdev_features_t features ) ;
2018-06-24 08:13:49 +03:00
struct sk_buff * tcp_gro_receive ( struct list_head * head , struct sk_buff * skb ) ;
2013-09-23 22:33:32 +04:00
int tcp_gro_complete ( struct sk_buff * skb ) ;
2013-06-07 09:11:46 +04:00
2013-09-23 22:33:32 +04:00
void __tcp_v4_send_check ( struct sk_buff * skb , __be32 saddr , __be32 daddr ) ;
2006-06-22 14:02:40 +04:00
tcp: TCP_NOTSENT_LOWAT socket option
Idea of this patch is to add optional limitation of number of
unsent bytes in TCP sockets, to reduce usage of kernel memory.
TCP receiver might announce a big window, and TCP sender autotuning
might allow a large amount of bytes in write queue, but this has little
performance impact if a large part of this buffering is wasted :
Write queue needs to be large only to deal with large BDP, not
necessarily to cope with scheduling delays (incoming ACKS make room
for the application to queue more bytes)
For most workloads, using a value of 128 KB or less is OK to give
applications enough time to react to POLLOUT events in time
(or being awaken in a blocking sendmsg())
This patch adds two ways to set the limit :
1) Per socket option TCP_NOTSENT_LOWAT
2) A sysctl (/proc/sys/net/ipv4/tcp_notsent_lowat) for sockets
not using TCP_NOTSENT_LOWAT socket option (or setting a zero value)
Default value being UINT_MAX (0xFFFFFFFF), meaning this has no effect.
This changes poll()/select()/epoll() to report POLLOUT
only if number of unsent bytes is below tp->nosent_lowat
Note this might increase number of sendmsg()/sendfile() calls
when using non blocking sockets,
and increase number of context switches for blocking sockets.
Note this is not related to SO_SNDLOWAT (as SO_SNDLOWAT is
defined as :
Specify the minimum number of bytes in the buffer until
the socket layer will pass the data to the protocol)
Tested:
netperf sessions, and watching /proc/net/protocols "memory" column for TCP
With 200 concurrent netperf -t TCP_STREAM sessions, amount of kernel memory
used by TCP buffers shrinks by ~55 % (20567 pages instead of 45458)
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 45458 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 45458 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 20567 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 20567 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
Using 128KB has no bad effect on the throughput or cpu usage
of a single flow, although there is an increase of context switches.
A bonus is that we hold socket lock for a shorter amount
of time and should improve latencies of ACK processing.
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1651584 6291456 16384 20.00 17447.90 10^6bits/s 3.13 S -1.00 U 0.353 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
412,514 context-switches
200.034645535 seconds time elapsed
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1593240 6291456 16384 20.00 17321.16 10^6bits/s 3.35 S -1.00 U 0.381 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
2,675,818 context-switches
200.029651391 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-By: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-07-23 07:27:07 +04:00
static inline u32 tcp_notsent_lowat ( const struct tcp_sock * tp )
{
2016-02-03 10:46:57 +03:00
struct net * net = sock_net ( ( struct sock * ) tp ) ;
return tp - > notsent_lowat ? : net - > ipv4 . sysctl_tcp_notsent_lowat ;
tcp: TCP_NOTSENT_LOWAT socket option
Idea of this patch is to add optional limitation of number of
unsent bytes in TCP sockets, to reduce usage of kernel memory.
TCP receiver might announce a big window, and TCP sender autotuning
might allow a large amount of bytes in write queue, but this has little
performance impact if a large part of this buffering is wasted :
Write queue needs to be large only to deal with large BDP, not
necessarily to cope with scheduling delays (incoming ACKS make room
for the application to queue more bytes)
For most workloads, using a value of 128 KB or less is OK to give
applications enough time to react to POLLOUT events in time
(or being awaken in a blocking sendmsg())
This patch adds two ways to set the limit :
1) Per socket option TCP_NOTSENT_LOWAT
2) A sysctl (/proc/sys/net/ipv4/tcp_notsent_lowat) for sockets
not using TCP_NOTSENT_LOWAT socket option (or setting a zero value)
Default value being UINT_MAX (0xFFFFFFFF), meaning this has no effect.
This changes poll()/select()/epoll() to report POLLOUT
only if number of unsent bytes is below tp->nosent_lowat
Note this might increase number of sendmsg()/sendfile() calls
when using non blocking sockets,
and increase number of context switches for blocking sockets.
Note this is not related to SO_SNDLOWAT (as SO_SNDLOWAT is
defined as :
Specify the minimum number of bytes in the buffer until
the socket layer will pass the data to the protocol)
Tested:
netperf sessions, and watching /proc/net/protocols "memory" column for TCP
With 200 concurrent netperf -t TCP_STREAM sessions, amount of kernel memory
used by TCP buffers shrinks by ~55 % (20567 pages instead of 45458)
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 45458 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 45458 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 20567 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 20567 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
Using 128KB has no bad effect on the throughput or cpu usage
of a single flow, although there is an increase of context switches.
A bonus is that we hold socket lock for a shorter amount
of time and should improve latencies of ACK processing.
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1651584 6291456 16384 20.00 17447.90 10^6bits/s 3.13 S -1.00 U 0.353 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
412,514 context-switches
200.034645535 seconds time elapsed
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1593240 6291456 16384 20.00 17321.16 10^6bits/s 3.35 S -1.00 U 0.381 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
2,675,818 context-switches
200.029651391 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-By: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-07-23 07:27:07 +04:00
}
2018-12-04 18:58:17 +03:00
/* @wake is one when sk_stream_write_space() calls us.
* This sends EPOLLOUT only if notsent_bytes is half the limit .
* This mimics the strategy used in sock_def_write_space ( ) .
*/
static inline bool tcp_stream_memory_free ( const struct sock * sk , int wake )
tcp: TCP_NOTSENT_LOWAT socket option
Idea of this patch is to add optional limitation of number of
unsent bytes in TCP sockets, to reduce usage of kernel memory.
TCP receiver might announce a big window, and TCP sender autotuning
might allow a large amount of bytes in write queue, but this has little
performance impact if a large part of this buffering is wasted :
Write queue needs to be large only to deal with large BDP, not
necessarily to cope with scheduling delays (incoming ACKS make room
for the application to queue more bytes)
For most workloads, using a value of 128 KB or less is OK to give
applications enough time to react to POLLOUT events in time
(or being awaken in a blocking sendmsg())
This patch adds two ways to set the limit :
1) Per socket option TCP_NOTSENT_LOWAT
2) A sysctl (/proc/sys/net/ipv4/tcp_notsent_lowat) for sockets
not using TCP_NOTSENT_LOWAT socket option (or setting a zero value)
Default value being UINT_MAX (0xFFFFFFFF), meaning this has no effect.
This changes poll()/select()/epoll() to report POLLOUT
only if number of unsent bytes is below tp->nosent_lowat
Note this might increase number of sendmsg()/sendfile() calls
when using non blocking sockets,
and increase number of context switches for blocking sockets.
Note this is not related to SO_SNDLOWAT (as SO_SNDLOWAT is
defined as :
Specify the minimum number of bytes in the buffer until
the socket layer will pass the data to the protocol)
Tested:
netperf sessions, and watching /proc/net/protocols "memory" column for TCP
With 200 concurrent netperf -t TCP_STREAM sessions, amount of kernel memory
used by TCP buffers shrinks by ~55 % (20567 pages instead of 45458)
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 45458 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 45458 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 20567 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 20567 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
Using 128KB has no bad effect on the throughput or cpu usage
of a single flow, although there is an increase of context switches.
A bonus is that we hold socket lock for a shorter amount
of time and should improve latencies of ACK processing.
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1651584 6291456 16384 20.00 17447.90 10^6bits/s 3.13 S -1.00 U 0.353 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
412,514 context-switches
200.034645535 seconds time elapsed
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1593240 6291456 16384 20.00 17321.16 10^6bits/s 3.35 S -1.00 U 0.381 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
2,675,818 context-switches
200.029651391 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-By: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-07-23 07:27:07 +04:00
{
const struct tcp_sock * tp = tcp_sk ( sk ) ;
2019-10-11 06:17:42 +03:00
u32 notsent_bytes = READ_ONCE ( tp - > write_seq ) -
READ_ONCE ( tp - > snd_nxt ) ;
tcp: TCP_NOTSENT_LOWAT socket option
Idea of this patch is to add optional limitation of number of
unsent bytes in TCP sockets, to reduce usage of kernel memory.
TCP receiver might announce a big window, and TCP sender autotuning
might allow a large amount of bytes in write queue, but this has little
performance impact if a large part of this buffering is wasted :
Write queue needs to be large only to deal with large BDP, not
necessarily to cope with scheduling delays (incoming ACKS make room
for the application to queue more bytes)
For most workloads, using a value of 128 KB or less is OK to give
applications enough time to react to POLLOUT events in time
(or being awaken in a blocking sendmsg())
This patch adds two ways to set the limit :
1) Per socket option TCP_NOTSENT_LOWAT
2) A sysctl (/proc/sys/net/ipv4/tcp_notsent_lowat) for sockets
not using TCP_NOTSENT_LOWAT socket option (or setting a zero value)
Default value being UINT_MAX (0xFFFFFFFF), meaning this has no effect.
This changes poll()/select()/epoll() to report POLLOUT
only if number of unsent bytes is below tp->nosent_lowat
Note this might increase number of sendmsg()/sendfile() calls
when using non blocking sockets,
and increase number of context switches for blocking sockets.
Note this is not related to SO_SNDLOWAT (as SO_SNDLOWAT is
defined as :
Specify the minimum number of bytes in the buffer until
the socket layer will pass the data to the protocol)
Tested:
netperf sessions, and watching /proc/net/protocols "memory" column for TCP
With 200 concurrent netperf -t TCP_STREAM sessions, amount of kernel memory
used by TCP buffers shrinks by ~55 % (20567 pages instead of 45458)
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 45458 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 45458 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 20567 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 20567 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
Using 128KB has no bad effect on the throughput or cpu usage
of a single flow, although there is an increase of context switches.
A bonus is that we hold socket lock for a shorter amount
of time and should improve latencies of ACK processing.
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1651584 6291456 16384 20.00 17447.90 10^6bits/s 3.13 S -1.00 U 0.353 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
412,514 context-switches
200.034645535 seconds time elapsed
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1593240 6291456 16384 20.00 17321.16 10^6bits/s 3.35 S -1.00 U 0.381 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
2,675,818 context-switches
200.029651391 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-By: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-07-23 07:27:07 +04:00
2018-12-04 18:58:17 +03:00
return ( notsent_bytes < < wake ) < tcp_notsent_lowat ( tp ) ;
tcp: TCP_NOTSENT_LOWAT socket option
Idea of this patch is to add optional limitation of number of
unsent bytes in TCP sockets, to reduce usage of kernel memory.
TCP receiver might announce a big window, and TCP sender autotuning
might allow a large amount of bytes in write queue, but this has little
performance impact if a large part of this buffering is wasted :
Write queue needs to be large only to deal with large BDP, not
necessarily to cope with scheduling delays (incoming ACKS make room
for the application to queue more bytes)
For most workloads, using a value of 128 KB or less is OK to give
applications enough time to react to POLLOUT events in time
(or being awaken in a blocking sendmsg())
This patch adds two ways to set the limit :
1) Per socket option TCP_NOTSENT_LOWAT
2) A sysctl (/proc/sys/net/ipv4/tcp_notsent_lowat) for sockets
not using TCP_NOTSENT_LOWAT socket option (or setting a zero value)
Default value being UINT_MAX (0xFFFFFFFF), meaning this has no effect.
This changes poll()/select()/epoll() to report POLLOUT
only if number of unsent bytes is below tp->nosent_lowat
Note this might increase number of sendmsg()/sendfile() calls
when using non blocking sockets,
and increase number of context switches for blocking sockets.
Note this is not related to SO_SNDLOWAT (as SO_SNDLOWAT is
defined as :
Specify the minimum number of bytes in the buffer until
the socket layer will pass the data to the protocol)
Tested:
netperf sessions, and watching /proc/net/protocols "memory" column for TCP
With 200 concurrent netperf -t TCP_STREAM sessions, amount of kernel memory
used by TCP buffers shrinks by ~55 % (20567 pages instead of 45458)
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 45458 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 45458 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# (super_netperf 200 -t TCP_STREAM -H remote -l 90 &); sleep 60 ; grep TCP /proc/net/protocols
TCPv6 1880 2 20567 no 208 yes ipv6 y y y y y y y y y y y y y n y y y y y
TCP 1696 508 20567 no 208 yes kernel y y y y y y y y y y y y y n y y y y y
Using 128KB has no bad effect on the throughput or cpu usage
of a single flow, although there is an increase of context switches.
A bonus is that we hold socket lock for a shorter amount
of time and should improve latencies of ACK processing.
lpq83:~# echo -1 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1651584 6291456 16384 20.00 17447.90 10^6bits/s 3.13 S -1.00 U 0.353 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
412,514 context-switches
200.034645535 seconds time elapsed
lpq83:~# echo 131072 >/proc/sys/net/ipv4/tcp_notsent_lowat
lpq83:~# perf stat -e context-switches ./netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3
OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.7.84 () port 0 AF_INET : +/-2.500% @ 99% conf.
Local Remote Local Elapsed Throughput Throughput Local Local Remote Remote Local Remote Service
Send Socket Recv Socket Send Time Units CPU CPU CPU CPU Service Service Demand
Size Size Size (sec) Util Util Util Util Demand Demand Units
Final Final % Method % Method
1593240 6291456 16384 20.00 17321.16 10^6bits/s 3.35 S -1.00 U 0.381 -1.000 usec/KB
Performance counter stats for './netperf -H 7.7.7.84 -t omni -l 20 -c -i10,3':
2,675,818 context-switches
200.029651391 seconds time elapsed
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Acked-By: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-07-23 07:27:07 +04:00
}
2005-08-16 09:18:02 +04:00
# ifdef CONFIG_PROC_FS
2013-09-23 22:33:32 +04:00
int tcp4_proc_init ( void ) ;
void tcp4_proc_exit ( void ) ;
2005-08-16 09:18:02 +04:00
# endif
2015-09-25 17:39:23 +03:00
int tcp_rtx_synack ( const struct sock * sk , struct request_sock * req ) ;
2014-06-25 18:10:02 +04:00
int tcp_conn_request ( struct request_sock_ops * rsk_ops ,
const struct tcp_request_sock_ops * af_ops ,
struct sock * sk , struct sk_buff * skb ) ;
2014-06-25 18:09:59 +04:00
2006-11-15 06:07:45 +03:00
/* TCP af-specific functions */
struct tcp_sock_af_ops {
# ifdef CONFIG_TCP_MD5SIG
2015-09-25 17:39:15 +03:00
struct tcp_md5sig_key * ( * md5_lookup ) ( const struct sock * sk ,
2015-03-25 01:58:56 +03:00
const struct sock * addr_sk ) ;
2015-03-25 01:58:55 +03:00
int ( * calc_md5_hash ) ( char * location ,
const struct tcp_md5sig_key * md5 ,
const struct sock * sk ,
const struct sk_buff * skb ) ;
int ( * md5_parse ) ( struct sock * sk ,
2017-06-16 04:07:07 +03:00
int optname ,
2015-03-25 01:58:55 +03:00
char __user * optval ,
int optlen ) ;
2006-11-15 06:07:45 +03:00
# endif
} ;
struct tcp_request_sock_ops {
2014-06-25 18:10:00 +04:00
u16 mss_clamp ;
2006-11-15 06:07:45 +03:00
# ifdef CONFIG_TCP_MD5SIG
2015-09-25 17:39:15 +03:00
struct tcp_md5sig_key * ( * req_md5_lookup ) ( const struct sock * sk ,
2015-03-25 01:58:56 +03:00
const struct sock * addr_sk ) ;
2015-03-25 01:58:55 +03:00
int ( * calc_md5_hash ) ( char * location ,
const struct tcp_md5sig_key * md5 ,
const struct sock * sk ,
const struct sk_buff * skb ) ;
2006-11-15 06:07:45 +03:00
# endif
2015-09-25 17:39:08 +03:00
void ( * init_req ) ( struct request_sock * req ,
const struct sock * sk_listener ,
2014-06-25 18:09:53 +04:00
struct sk_buff * skb ) ;
2014-06-25 18:09:54 +04:00
# ifdef CONFIG_SYN_COOKIES
2015-09-29 17:42:49 +03:00
__u32 ( * cookie_init_seq ) ( const struct sk_buff * skb ,
2014-06-25 18:09:54 +04:00
__u16 * mss ) ;
# endif
2015-09-29 17:42:50 +03:00
struct dst_entry * ( * route_req ) ( const struct sock * sk , struct flowi * fl ,
2017-03-15 23:30:46 +03:00
const struct request_sock * req ) ;
2017-05-05 16:56:54 +03:00
u32 ( * init_seq ) ( const struct sk_buff * skb ) ;
2017-06-07 20:34:39 +03:00
u32 ( * init_ts_off ) ( const struct net * net , const struct sk_buff * skb ) ;
2015-09-25 17:39:21 +03:00
int ( * send_synack ) ( const struct sock * sk , struct dst_entry * dst ,
2014-06-25 18:09:58 +04:00
struct flowi * fl , struct request_sock * req ,
2015-10-16 23:00:01 +03:00
struct tcp_fastopen_cookie * foc ,
2016-04-14 08:05:39 +03:00
enum tcp_synack_type synack_type ) ;
2006-11-15 06:07:45 +03:00
} ;
2020-01-09 18:59:21 +03:00
extern const struct tcp_request_sock_ops tcp_request_sock_ipv4_ops ;
# if IS_ENABLED(CONFIG_IPV6)
extern const struct tcp_request_sock_ops tcp_request_sock_ipv6_ops ;
# endif
2014-06-25 18:09:54 +04:00
# ifdef CONFIG_SYN_COOKIES
static inline __u32 cookie_init_sequence ( const struct tcp_request_sock_ops * ops ,
2015-09-29 17:42:49 +03:00
const struct sock * sk , struct sk_buff * skb ,
2014-06-25 18:09:54 +04:00
__u16 * mss )
{
2015-09-29 17:42:49 +03:00
tcp_synq_overflow ( sk ) ;
2016-04-28 02:44:39 +03:00
__NET_INC_STATS ( sock_net ( sk ) , LINUX_MIB_SYNCOOKIESSENT ) ;
2015-09-29 17:42:49 +03:00
return ops - > cookie_init_seq ( skb , mss ) ;
2014-06-25 18:09:54 +04:00
}
# else
static inline __u32 cookie_init_sequence ( const struct tcp_request_sock_ops * ops ,
2015-09-29 17:42:49 +03:00
const struct sock * sk , struct sk_buff * skb ,
2014-06-25 18:09:54 +04:00
__u16 * mss )
{
return 0 ;
}
# endif
2013-09-23 22:33:32 +04:00
int tcpv4_offload_init ( void ) ;
2013-06-07 09:11:46 +04:00
2013-09-23 22:33:32 +04:00
void tcp_v4_init ( void ) ;
void tcp_init ( void ) ;
2005-08-16 09:18:02 +04:00
2015-10-17 07:57:46 +03:00
/* tcp_recovery.c */
2018-05-17 02:40:13 +03:00
void tcp_mark_skb_lost ( struct sock * sk , struct sk_buff * skb ) ;
2018-05-17 02:40:12 +03:00
void tcp_newreno_mark_lost ( struct sock * sk , bool snd_una_advanced ) ;
2018-05-17 02:40:16 +03:00
extern s32 tcp_rack_skb_timeout ( struct tcp_sock * tp , struct sk_buff * skb ,
u32 reo_wnd ) ;
2017-04-25 20:15:34 +03:00
extern void tcp_rack_mark_lost ( struct sock * sk ) ;
2017-01-13 09:11:34 +03:00
extern void tcp_rack_advance ( struct tcp_sock * tp , u8 sacked , u32 end_seq ,
2017-05-17 00:00:14 +03:00
u64 xmit_time ) ;
2017-01-13 09:11:33 +03:00
extern void tcp_rack_reo_timeout ( struct sock * sk ) ;
2017-11-04 02:38:48 +03:00
extern void tcp_rack_update_reo_wnd ( struct sock * sk , struct rate_sample * rs ) ;
2015-10-17 07:57:46 +03:00
2017-08-03 16:19:52 +03:00
/* At how many usecs into the future should the RTO fire? */
static inline s64 tcp_rto_delta_us ( const struct sock * sk )
{
2017-10-06 08:21:27 +03:00
const struct sk_buff * skb = tcp_rtx_queue_head ( sk ) ;
2017-08-03 16:19:52 +03:00
u32 rto = inet_csk ( sk ) - > icsk_rto ;
2018-09-21 18:51:47 +03:00
u64 rto_time_stamp_us = tcp_skb_timestamp_us ( skb ) + jiffies_to_usecs ( rto ) ;
2017-08-03 16:19:52 +03:00
return rto_time_stamp_us - tcp_sk ( sk ) - > tcp_mstamp ;
}
2014-10-16 01:33:21 +04:00
/*
* Save and compile IPv4 options , return a pointer to it
*/
2017-08-03 19:07:06 +03:00
static inline struct ip_options_rcu * tcp_v4_save_options ( struct net * net ,
struct sk_buff * skb )
2014-10-16 01:33:21 +04:00
{
const struct ip_options * opt = & TCP_SKB_CB ( skb ) - > header . h4 . opt ;
struct ip_options_rcu * dopt = NULL ;
2014-10-16 01:33:22 +04:00
if ( opt - > optlen ) {
2014-10-16 01:33:21 +04:00
int opt_size = sizeof ( * dopt ) + opt - > optlen ;
dopt = kmalloc ( opt_size , GFP_ATOMIC ) ;
2017-08-03 19:07:06 +03:00
if ( dopt & & __ip_options_echo ( net , & dopt - > opt , skb , opt ) ) {
2014-10-16 01:33:21 +04:00
kfree ( dopt ) ;
dopt = NULL ;
}
}
return dopt ;
}
tcp: do not pace pure ack packets
When we added pacing to TCP, we decided to let sch_fq take care
of actual pacing.
All TCP had to do was to compute sk->pacing_rate using simple formula:
sk->pacing_rate = 2 * cwnd * mss / rtt
It works well for senders (bulk flows), but not very well for receivers
or even RPC :
cwnd on the receiver can be less than 10, rtt can be around 100ms, so we
can end up pacing ACK packets, slowing down the sender.
Really, only the sender should pace, according to its own logic.
Instead of adding a new bit in skb, or call yet another flow
dissection, we tweak skb->truesize to a small value (2), and
we instruct sch_fq to use new helper and not pace pure ack.
Note this also helps TCP small queue, as ack packets present
in qdisc/NIC do not prevent sending a data packet (RPC workload)
This helps to reduce tx completion overhead, ack packets can use regular
sock_wfree() instead of tcp_wfree() which is a bit more expensive.
This has no impact in the case packets are sent to loopback interface,
as we do not coalesce ack packets (were we would detect skb->truesize
lie)
In case netem (with a delay) is used, skb_orphan_partial() also sets
skb->truesize to 1.
This patch is a combination of two patches we used for about one year at
Google.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-04 05:31:53 +03:00
/* locally generated TCP pure ACKs have skb->truesize == 2
* ( check tcp_send_ack ( ) in net / ipv4 / tcp_output . c )
* This is much faster than dissecting the packet to find out .
* ( Think of GRE encapsulations , IPv4 , IPv6 , . . . )
*/
static inline bool skb_is_tcp_pure_ack ( const struct sk_buff * skb )
{
return skb - > truesize = = 2 ;
}
static inline void skb_set_tcp_pure_ack ( struct sk_buff * skb )
{
skb - > truesize = 2 ;
}
2016-03-08 01:11:05 +03:00
static inline int tcp_inq ( struct sock * sk )
{
struct tcp_sock * tp = tcp_sk ( sk ) ;
int answ ;
if ( ( 1 < < sk - > sk_state ) & ( TCPF_SYN_SENT | TCPF_SYN_RECV ) ) {
answ = 0 ;
} else if ( sock_flag ( sk , SOCK_URGINLINE ) | |
! tp - > urg_data | |
before ( tp - > urg_seq , tp - > copied_seq ) | |
! before ( tp - > urg_seq , tp - > rcv_nxt ) ) {
answ = tp - > rcv_nxt - tp - > copied_seq ;
/* Subtract 1, if FIN was received */
if ( answ & & sock_flag ( sk , SOCK_DONE ) )
answ - - ;
} else {
answ = tp - > urg_seq - tp - > copied_seq ;
}
return answ ;
}
2016-08-29 00:43:18 +03:00
int tcp_peek_len ( struct socket * sock ) ;
2016-03-14 20:52:15 +03:00
static inline void tcp_segs_in ( struct tcp_sock * tp , const struct sk_buff * skb )
{
u16 segs_in ;
segs_in = max_t ( u16 , 1 , skb_shinfo ( skb ) - > gso_segs ) ;
tp - > segs_in + = segs_in ;
if ( skb - > len > tcp_hdrlen ( skb ) )
tp - > data_segs_in + = segs_in ;
}
2016-04-01 18:52:20 +03:00
/*
* TCP listen path runs lockless .
* We forced " struct sock " to be const qualified to make sure
* we don ' t modify one of its field by mistake .
* Here , we increment sk_drops which is an atomic_t , so we can safely
* make sock writable again .
*/
static inline void tcp_listendrop ( const struct sock * sk )
{
atomic_inc ( & ( ( struct sock * ) sk ) - > sk_drops ) ;
2016-04-28 02:44:39 +03:00
__NET_INC_STATS ( sock_net ( sk ) , LINUX_MIB_LISTENDROPS ) ;
2016-04-01 18:52:20 +03:00
}
2017-05-16 14:24:36 +03:00
enum hrtimer_restart tcp_pace_kick ( struct hrtimer * timer ) ;
2017-06-14 21:37:14 +03:00
/*
* Interface for adding Upper Level Protocols over TCP
*/
# define TCP_ULP_NAME_MAX 16
# define TCP_ULP_MAX 128
# define TCP_ULP_BUF_MAX (TCP_ULP_NAME_MAX*TCP_ULP_MAX)
struct tcp_ulp_ops {
struct list_head list ;
/* initialize ulp */
int ( * init ) ( struct sock * sk ) ;
2019-07-19 20:29:22 +03:00
/* update ulp */
2020-01-11 09:12:01 +03:00
void ( * update ) ( struct sock * sk , struct proto * p ,
void ( * write_space ) ( struct sock * sk ) ) ;
2017-06-14 21:37:14 +03:00
/* cleanup ulp */
void ( * release ) ( struct sock * sk ) ;
2019-08-30 13:25:48 +03:00
/* diagnostic */
int ( * get_info ) ( const struct sock * sk , struct sk_buff * skb ) ;
size_t ( * get_info_size ) ( const struct sock * sk ) ;
2020-01-09 18:59:18 +03:00
/* clone ulp */
void ( * clone ) ( const struct request_sock * req , struct sock * newsk ,
const gfp_t priority ) ;
2017-06-14 21:37:14 +03:00
char name [ TCP_ULP_NAME_MAX ] ;
struct module * owner ;
} ;
int tcp_register_ulp ( struct tcp_ulp_ops * type ) ;
void tcp_unregister_ulp ( struct tcp_ulp_ops * type ) ;
int tcp_set_ulp ( struct sock * sk , const char * name ) ;
void tcp_get_available_ulp ( char * buf , size_t len ) ;
void tcp_cleanup_ulp ( struct sock * sk ) ;
2020-01-11 09:12:01 +03:00
void tcp_update_ulp ( struct sock * sk , struct proto * p ,
void ( * write_space ) ( struct sock * sk ) ) ;
2017-06-14 21:37:14 +03:00
tcp, ulp: add alias for all ulp modules
Lets not turn the TCP ULP lookup into an arbitrary module loader as
we only intend to load ULP modules through this mechanism, not other
unrelated kernel modules:
[root@bar]# cat foo.c
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/tcp.h>
#include <linux/in.h>
int main(void)
{
int sock = socket(PF_INET, SOCK_STREAM, 0);
setsockopt(sock, IPPROTO_TCP, TCP_ULP, "sctp", sizeof("sctp"));
return 0;
}
[root@bar]# gcc foo.c -O2 -Wall
[root@bar]# lsmod | grep sctp
[root@bar]# ./a.out
[root@bar]# lsmod | grep sctp
sctp 1077248 4
libcrc32c 16384 3 nf_conntrack,nf_nat,sctp
[root@bar]#
Fix it by adding module alias to TCP ULP modules, so probing module
via request_module() will be limited to tcp-ulp-[name]. The existing
modules like kTLS will load fine given tcp-ulp-tls alias, but others
will fail to load:
[root@bar]# lsmod | grep sctp
[root@bar]# ./a.out
[root@bar]# lsmod | grep sctp
[root@bar]#
Sockmap is not affected from this since it's either built-in or not.
Fixes: 734942cc4ea6 ("tcp: ULP infrastructure")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-08-16 22:49:06 +03:00
# define MODULE_ALIAS_TCP_ULP(name) \
__MODULE_INFO ( alias , alias_userspace , name ) ; \
__MODULE_INFO ( alias , alias_tcp_ulp , " tcp-ulp- " name )
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 03:45:58 +03:00
struct sk_msg ;
struct sk_psock ;
2020-03-09 14:12:36 +03:00
# ifdef CONFIG_BPF_STREAM_PARSER
struct proto * tcp_bpf_get_proto ( struct sock * sk , struct sk_psock * psock ) ;
void tcp_bpf_clone ( const struct sock * sk , struct sock * newsk ) ;
# else
static inline void tcp_bpf_clone ( const struct sock * sk , struct sock * newsk )
{
}
# endif /* CONFIG_BPF_STREAM_PARSER */
2020-03-09 14:12:35 +03:00
# ifdef CONFIG_NET_SOCK_MSG
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 03:45:58 +03:00
int tcp_bpf_sendmsg_redir ( struct sock * sk , struct sk_msg * msg , u32 bytes ,
int flags ) ;
int __tcp_bpf_recvmsg ( struct sock * sk , struct sk_psock * psock ,
2018-10-16 21:08:04 +03:00
struct msghdr * msg , int len , int flags ) ;
2020-03-09 14:12:35 +03:00
# endif /* CONFIG_NET_SOCK_MSG */
bpf, sockmap: convert to generic sk_msg interface
Add a generic sk_msg layer, and convert current sockmap and later
kTLS over to make use of it. While sk_buff handles network packet
representation from netdevice up to socket, sk_msg handles data
representation from application to socket layer.
This means that sk_msg framework spans across ULP users in the
kernel, and enables features such as introspection or filtering
of data with the help of BPF programs that operate on this data
structure.
Latter becomes in particular useful for kTLS where data encryption
is deferred into the kernel, and as such enabling the kernel to
perform L7 introspection and policy based on BPF for TLS connections
where the record is being encrypted after BPF has run and came to
a verdict. In order to get there, first step is to transform open
coding of scatter-gather list handling into a common core framework
that subsystems can use.
The code itself has been split and refactored into three bigger
pieces: i) the generic sk_msg API which deals with managing the
scatter gather ring, providing helpers for walking and mangling,
transferring application data from user space into it, and preparing
it for BPF pre/post-processing, ii) the plain sock map itself
where sockets can be attached to or detached from; these bits
are independent of i) which can now be used also without sock
map, and iii) the integration with plain TCP as one protocol
to be used for processing L7 application data (later this could
e.g. also be extended to other protocols like UDP). The semantics
are the same with the old sock map code and therefore no change
of user facing behavior or APIs. While pursuing this work it
also helped finding a number of bugs in the old sockmap code
that we've fixed already in earlier commits. The test_sockmap
kselftest suite passes through fine as well.
Joint work with John.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-10-13 03:45:58 +03:00
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
/* Call BPF_SOCK_OPS program that returns an int. If the return value
* is < 0 , then the BPF op failed ( for example if the loaded BPF
* program does not support the chosen operation or there is no BPF
* program loaded ) .
*/
# ifdef CONFIG_BPF
2018-01-26 03:14:09 +03:00
static inline int tcp_call_bpf ( struct sock * sk , int op , u32 nargs , u32 * args )
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
{
struct bpf_sock_ops_kern sock_ops ;
int ret ;
2018-01-26 03:14:08 +03:00
memset ( & sock_ops , 0 , offsetof ( struct bpf_sock_ops_kern , temp ) ) ;
2017-12-01 21:15:04 +03:00
if ( sk_fullsock ( sk ) ) {
sock_ops . is_fullsock = 1 ;
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
sock_owned_by_me ( sk ) ;
2017-12-01 21:15:04 +03:00
}
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
sock_ops . sk = sk ;
sock_ops . op = op ;
2018-01-26 03:14:09 +03:00
if ( nargs > 0 )
memcpy ( sock_ops . args , args , nargs * sizeof ( * args ) ) ;
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
ret = BPF_CGROUP_RUN_PROG_SOCK_OPS ( & sock_ops ) ;
if ( ret = = 0 )
ret = sock_ops . reply ;
else
ret = - 1 ;
return ret ;
}
2018-01-26 03:14:09 +03:00
static inline int tcp_call_bpf_2arg ( struct sock * sk , int op , u32 arg1 , u32 arg2 )
{
u32 args [ 2 ] = { arg1 , arg2 } ;
return tcp_call_bpf ( sk , op , 2 , args ) ;
}
static inline int tcp_call_bpf_3arg ( struct sock * sk , int op , u32 arg1 , u32 arg2 ,
u32 arg3 )
{
u32 args [ 3 ] = { arg1 , arg2 , arg3 } ;
return tcp_call_bpf ( sk , op , 3 , args ) ;
}
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
# else
2018-01-26 03:14:09 +03:00
static inline int tcp_call_bpf ( struct sock * sk , int op , u32 nargs , u32 * args )
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
{
return - EPERM ;
}
2018-01-26 03:14:09 +03:00
static inline int tcp_call_bpf_2arg ( struct sock * sk , int op , u32 arg1 , u32 arg2 )
{
return - EPERM ;
}
static inline int tcp_call_bpf_3arg ( struct sock * sk , int op , u32 arg1 , u32 arg2 ,
u32 arg3 )
{
return - EPERM ;
}
bpf: BPF support for sock_ops
Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
Alghough there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) beccause the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.
This patch only contains the framework to support the new BPF program
type, following patches add the functionality to set various connection
parameters.
This patch defines a new BPF program type: BPF_PROG_TYPE_SOCKET_OPS
and a new bpf syscall command to load a new program of this type:
BPF_PROG_LOAD_SOCKET_OPS.
Two new corresponding structs (one for the kernel one for the user/BPF
program):
/* kernel version */
struct bpf_sock_ops_kern {
struct sock *sk;
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
};
/* user version
* Some fields are in network byte order reflecting the sock struct
* Use the bpf_ntohl helper macro in samples/bpf/bpf_endian.h to
* convert them to host byte order.
*/
struct bpf_sock_ops {
__u32 op;
union {
__u32 reply;
__u32 replylong[4];
};
__u32 family;
__u32 remote_ip4; /* In network byte order */
__u32 local_ip4; /* In network byte order */
__u32 remote_ip6[4]; /* In network byte order */
__u32 local_ip6[4]; /* In network byte order */
__u32 remote_port; /* In network byte order */
__u32 local_port; /* In host byte horder */
};
Currently there are two types of ops. The first type expects the BPF
program to return a value which is then used by the caller (or a
negative value to indicate the operation is not supported). The second
type expects state changes to be done by the BPF program, for example
through a setsockopt BPF helper function, and they ignore the return
value.
The reply fields of the bpf_sockt_ops struct are there in case a bpf
program needs to return a value larger than an integer.
Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-01 06:02:40 +03:00
# endif
2017-07-01 06:02:42 +03:00
static inline u32 tcp_timeout_init ( struct sock * sk )
{
int timeout ;
2018-01-26 03:14:09 +03:00
timeout = tcp_call_bpf ( sk , BPF_SOCK_OPS_TIMEOUT_INIT , 0 , NULL ) ;
2017-07-01 06:02:42 +03:00
if ( timeout < = 0 )
timeout = TCP_TIMEOUT_INIT ;
return timeout ;
}
2017-07-01 06:02:44 +03:00
static inline u32 tcp_rwnd_init_bpf ( struct sock * sk )
{
int rwnd ;
2018-01-26 03:14:09 +03:00
rwnd = tcp_call_bpf ( sk , BPF_SOCK_OPS_RWND_INIT , 0 , NULL ) ;
2017-07-01 06:02:44 +03:00
if ( rwnd < 0 )
rwnd = 0 ;
return rwnd ;
}
2017-07-01 06:02:49 +03:00
static inline bool tcp_bpf_ca_needs_ecn ( struct sock * sk )
{
2018-01-26 03:14:09 +03:00
return ( tcp_call_bpf ( sk , BPF_SOCK_OPS_NEEDS_ECN , 0 , NULL ) = = 1 ) ;
2017-07-01 06:02:49 +03:00
}
2017-10-25 12:01:45 +03:00
2019-07-02 19:13:56 +03:00
static inline void tcp_bpf_rtt ( struct sock * sk )
{
2019-07-08 15:57:21 +03:00
if ( BPF_SOCK_OPS_TEST_FLAG ( tcp_sk ( sk ) , BPF_SOCK_OPS_RTT_CB_FLAG ) )
2019-07-02 19:13:56 +03:00
tcp_call_bpf ( sk , BPF_SOCK_OPS_RTT_CB , 0 , NULL ) ;
}
2017-10-25 12:01:45 +03:00
# if IS_ENABLED(CONFIG_SMC)
extern struct static_key_false tcp_have_smc ;
# endif
2018-04-30 10:16:10 +03:00
# if IS_ENABLED(CONFIG_TLS_DEVICE)
void clean_acked_data_enable ( struct inet_connection_sock * icsk ,
void ( * cad ) ( struct sock * sk , u32 ack_seq ) ) ;
void clean_acked_data_disable ( struct inet_connection_sock * icsk ) ;
2019-05-09 02:46:14 +03:00
void clean_acked_data_flush ( void ) ;
2018-04-30 10:16:10 +03:00
# endif
tcp: add optional per socket transmit delay
Adding delays to TCP flows is crucial for studying behavior
of TCP stacks, including congestion control modules.
Linux offers netem module, but it has unpractical constraints :
- Need root access to change qdisc
- Hard to setup on egress if combined with non trivial qdisc like FQ
- Single delay for all flows.
EDT (Earliest Departure Time) adoption in TCP stack allows us
to enable a per socket delay at a very small cost.
Networking tools can now establish thousands of flows, each of them
with a different delay, simulating real world conditions.
This requires FQ packet scheduler or a EDT-enabled NIC.
This patchs adds TCP_TX_DELAY socket option, to set a delay in
usec units.
unsigned int tx_delay = 10000; /* 10 msec */
setsockopt(fd, SOL_TCP, TCP_TX_DELAY, &tx_delay, sizeof(tx_delay));
Note that FQ packet scheduler limits might need some tweaking :
man tc-fq
PARAMETERS
limit
Hard limit on the real queue size. When this limit is
reached, new packets are dropped. If the value is lowered,
packets are dropped so that the new limit is met. Default
is 10000 packets.
flow_limit
Hard limit on the maximum number of packets queued per
flow. Default value is 100.
Use of TCP_TX_DELAY option will increase number of skbs in FQ qdisc,
so packets would be dropped if any of the previous limit is hit.
Use of a jump label makes this support runtime-free, for hosts
never using the option.
Also note that TSQ (TCP Small Queues) limits are slightly changed
with this patch : we need to account that skbs artificially delayed
wont stop us providind more skbs to feed the pipe (netem uses
skb_orphan_partial() for this purpose, but FQ can not use this trick)
Because of that, using big delays might very well trigger
old bugs in TSO auto defer logic and/or sndbuf limited detection.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-12 21:57:25 +03:00
DECLARE_STATIC_KEY_FALSE ( tcp_tx_delay_enabled ) ;
static inline void tcp_add_tx_delay ( struct sk_buff * skb ,
const struct tcp_sock * tp )
{
if ( static_branch_unlikely ( & tcp_tx_delay_enabled ) )
skb - > skb_mstamp_ns + = ( u64 ) tp - > tcp_tx_delay * NSEC_PER_USEC ;
}
2019-06-14 07:22:35 +03:00
/* Compute Earliest Departure Time for some control packets
* like ACK or RST for TIME_WAIT or non ESTABLISHED sockets .
*/
static inline u64 tcp_transmit_time ( const struct sock * sk )
tcp: add optional per socket transmit delay
Adding delays to TCP flows is crucial for studying behavior
of TCP stacks, including congestion control modules.
Linux offers netem module, but it has unpractical constraints :
- Need root access to change qdisc
- Hard to setup on egress if combined with non trivial qdisc like FQ
- Single delay for all flows.
EDT (Earliest Departure Time) adoption in TCP stack allows us
to enable a per socket delay at a very small cost.
Networking tools can now establish thousands of flows, each of them
with a different delay, simulating real world conditions.
This requires FQ packet scheduler or a EDT-enabled NIC.
This patchs adds TCP_TX_DELAY socket option, to set a delay in
usec units.
unsigned int tx_delay = 10000; /* 10 msec */
setsockopt(fd, SOL_TCP, TCP_TX_DELAY, &tx_delay, sizeof(tx_delay));
Note that FQ packet scheduler limits might need some tweaking :
man tc-fq
PARAMETERS
limit
Hard limit on the real queue size. When this limit is
reached, new packets are dropped. If the value is lowered,
packets are dropped so that the new limit is met. Default
is 10000 packets.
flow_limit
Hard limit on the maximum number of packets queued per
flow. Default value is 100.
Use of TCP_TX_DELAY option will increase number of skbs in FQ qdisc,
so packets would be dropped if any of the previous limit is hit.
Use of a jump label makes this support runtime-free, for hosts
never using the option.
Also note that TSQ (TCP Small Queues) limits are slightly changed
with this patch : we need to account that skbs artificially delayed
wont stop us providind more skbs to feed the pipe (netem uses
skb_orphan_partial() for this purpose, but FQ can not use this trick)
Because of that, using big delays might very well trigger
old bugs in TSO auto defer logic and/or sndbuf limited detection.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-12 21:57:25 +03:00
{
if ( static_branch_unlikely ( & tcp_tx_delay_enabled ) ) {
u32 delay = ( sk - > sk_state = = TCP_TIME_WAIT ) ?
tcp_twsk ( sk ) - > tw_tx_delay : tcp_sk ( sk ) - > tcp_tx_delay ;
2019-06-14 07:22:35 +03:00
return tcp_clock_ns ( ) + ( u64 ) delay * NSEC_PER_USEC ;
tcp: add optional per socket transmit delay
Adding delays to TCP flows is crucial for studying behavior
of TCP stacks, including congestion control modules.
Linux offers netem module, but it has unpractical constraints :
- Need root access to change qdisc
- Hard to setup on egress if combined with non trivial qdisc like FQ
- Single delay for all flows.
EDT (Earliest Departure Time) adoption in TCP stack allows us
to enable a per socket delay at a very small cost.
Networking tools can now establish thousands of flows, each of them
with a different delay, simulating real world conditions.
This requires FQ packet scheduler or a EDT-enabled NIC.
This patchs adds TCP_TX_DELAY socket option, to set a delay in
usec units.
unsigned int tx_delay = 10000; /* 10 msec */
setsockopt(fd, SOL_TCP, TCP_TX_DELAY, &tx_delay, sizeof(tx_delay));
Note that FQ packet scheduler limits might need some tweaking :
man tc-fq
PARAMETERS
limit
Hard limit on the real queue size. When this limit is
reached, new packets are dropped. If the value is lowered,
packets are dropped so that the new limit is met. Default
is 10000 packets.
flow_limit
Hard limit on the maximum number of packets queued per
flow. Default value is 100.
Use of TCP_TX_DELAY option will increase number of skbs in FQ qdisc,
so packets would be dropped if any of the previous limit is hit.
Use of a jump label makes this support runtime-free, for hosts
never using the option.
Also note that TSQ (TCP Small Queues) limits are slightly changed
with this patch : we need to account that skbs artificially delayed
wont stop us providind more skbs to feed the pipe (netem uses
skb_orphan_partial() for this purpose, but FQ can not use this trick)
Because of that, using big delays might very well trigger
old bugs in TSO auto defer logic and/or sndbuf limited detection.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-12 21:57:25 +03:00
}
2019-06-14 07:22:35 +03:00
return 0 ;
tcp: add optional per socket transmit delay
Adding delays to TCP flows is crucial for studying behavior
of TCP stacks, including congestion control modules.
Linux offers netem module, but it has unpractical constraints :
- Need root access to change qdisc
- Hard to setup on egress if combined with non trivial qdisc like FQ
- Single delay for all flows.
EDT (Earliest Departure Time) adoption in TCP stack allows us
to enable a per socket delay at a very small cost.
Networking tools can now establish thousands of flows, each of them
with a different delay, simulating real world conditions.
This requires FQ packet scheduler or a EDT-enabled NIC.
This patchs adds TCP_TX_DELAY socket option, to set a delay in
usec units.
unsigned int tx_delay = 10000; /* 10 msec */
setsockopt(fd, SOL_TCP, TCP_TX_DELAY, &tx_delay, sizeof(tx_delay));
Note that FQ packet scheduler limits might need some tweaking :
man tc-fq
PARAMETERS
limit
Hard limit on the real queue size. When this limit is
reached, new packets are dropped. If the value is lowered,
packets are dropped so that the new limit is met. Default
is 10000 packets.
flow_limit
Hard limit on the maximum number of packets queued per
flow. Default value is 100.
Use of TCP_TX_DELAY option will increase number of skbs in FQ qdisc,
so packets would be dropped if any of the previous limit is hit.
Use of a jump label makes this support runtime-free, for hosts
never using the option.
Also note that TSQ (TCP Small Queues) limits are slightly changed
with this patch : we need to account that skbs artificially delayed
wont stop us providind more skbs to feed the pipe (netem uses
skb_orphan_partial() for this purpose, but FQ can not use this trick)
Because of that, using big delays might very well trigger
old bugs in TSO auto defer logic and/or sndbuf limited detection.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-12 21:57:25 +03:00
}
2005-04-17 02:20:36 +04:00
# endif /* _TCP_H */
