netdev - Re: [PATCH net-next] tcp: give prequeue mode some care

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Apr 2016 17:15:14 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tcp: give prequeue mode some care

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Wed, 27 Apr 2016 10:12:25 -0700

> From: Eric Dumazet <edumazet@...gle.com>
> 
> TCP prequeue goal is to defer processing of incoming packets
> to user space thread currently blocked in a recvmsg() system call.
> 
> Intent is to spend less time processing these packets on behalf
> of softirq handler, as softirq handler is unfair to normal process
> scheduler decisions, as it might interrupt threads that do not
> even use networking.
> 
> Current prequeue implementation has following issues :
> 
> 1) It only checks size of the prequeue against sk_rcvbuf
> 
>    It was fine 15 years ago when sk_rcvbuf was in the 64KB vicinity.
>    But we now have ~8MB values to cope with modern networking needs.
>    We have to add sk_rmem_alloc in the equation, since out of order
>    packets can definitely use up to sk_rcvbuf memory themselves.
> 
> 2) Even with a fixed memory truesize check, prequeue can be filled
>    by thousands of packets. When prequeue needs to be flushed, either
>    from sofirq context (in tcp_prequeue() or timer code), or process
>    context (in tcp_prequeue_process()), this adds a latency spike
>    which is often not desirable.
>    I added a fixed limit of 32 packets, as this translated to a max
>    flush time of 60 us on my test hosts.
> 
>    Also note that all packets in prequeue are not accounted for tcp_mem,
>    since they are not charged against sk_forward_alloc at this point.
>    This is probably not a big deal.
> 
> Note that this might increase LINUX_MIB_TCPPREQUEUEDROPPED counts,
> which is misnamed, as packets are not dropped at all, but rather pushed
> to the stack (where they can be either consumed or dropped)
> 
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

There was a conflict due to the stats macro renaming, but that was trivial
to resolve so I did it.

Applied, thanks Eric.