netdev - Re: [PATCH v2 net-next 0/3] tcp: add rx/tx cache to reduce lock contention

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CANn89i++H531xyH_pp=LZe362_+uyrDGQNmRQ8wALmjaFW3TEw@mail.gmail.com>
Date:   Fri, 22 Mar 2019 05:49:27 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Soheil Hassas Yeganeh <soheil@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Florian Westphal <fw@...len.de>,
        Tom Herbert <tom@...bertland.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH v2 net-next 0/3] tcp: add rx/tx cache to reduce lock contention

On Fri, Mar 22, 2019 at 4:28 AM Michael S. Tsirkin <mst@...hat.com> wrote:
>
>
> Just a thought: would it make sense to flush the cache
> in enter_memory_pressure?
>

Good question, thanks !

Willem asked me something similar yesterday.

The argument of keeping one skb for tx and one for rx makes some sense
to me, since it will more or less facilitate forward progress.

References :
 commit  8e4d980ac215 ("tcp: fix behavior for epoll edge trigger")
 commit eb9344781a2f8 ("tcp: add a force_schedule argument to
sk_stream_alloc_skb()")

The global tcp_memory_pressure status should play its role for
elephant flows (not the RPC workload targeted by this patch series),
so that they gradually reduce their memory usage to the minimum of one
packet per TCP flow.