Last known hot point during SYNFLOOD attack is the clearing
of rx_opt.saw_tstamp in tcp_rcv_state_process()

It is not needed for a listener, so we move it where it matters.

Performance while a SYNFLOOD hits a single listener socket
went from 5 Mpps to 6 Mpps on my test server (24 cores, 8 NIC RX queues)

Signed-off-by: Eric Dumazet <eduma...@google.com>
---
 net/ipv4/tcp_input.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 7ea7034af83f..90e0d9256b74 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5796,8 +5796,6 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff 
*skb)
        int queued = 0;
        bool acceptable;
 
-       tp->rx_opt.saw_tstamp = 0;
-
        switch (sk->sk_state) {
        case TCP_CLOSE:
                goto discard;
@@ -5838,6 +5836,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff 
*skb)
                goto discard;
 
        case TCP_SYN_SENT:
+               tp->rx_opt.saw_tstamp = 0;
                queued = tcp_rcv_synsent_state_process(sk, skb, th);
                if (queued >= 0)
                        return queued;
@@ -5849,6 +5848,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff 
*skb)
                return 0;
        }
 
+       tp->rx_opt.saw_tstamp = 0;
        req = tp->fastopen_rsk;
        if (req) {
                WARN_ON_ONCE(sk->sk_state != TCP_SYN_RECV &&
-- 
2.8.0.rc3.226.g39d4020

Reply via email to