Re: [RFC net-next 4/4] tcp: defer regular ACK while processing socket backlog

[Eric Dumazet <edumazet@google.com>]

On Thu, Sep 7, 2023 at 8:00 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 7 Sep 2023 19:16:01 +0200 Eric Dumazet wrote:
> > > Is it okay if I asked why quickack?
> > > Is it related to delay-based CC?
> >
> > Note the patch is also helping the 'regular' mode, without "quickack 1" .
> >
> > This is CC related in any way, but some TCP tx zerocopy workload, sending
> > one chunk at a time, waiting for the TCP tx zerocopy completion in
> > order to proceed for the next chunk,
> > because the 'next chunk'  is re-using the memory.
> >
> > The receiver application is not sending back a message (otherwise the
> > 'delayed ack' would be piggybacked in the reply),
> > and it also does not know what size of the message was expected (so no
> > SO_RCVLOWAT or anything could be attempted)
> >
> > For this kind of workload, it is crucial the last ACK is not delayed, at all.
>
> Interesting. Some folks at Meta were recently looking into parsing RPCs
> in the kernel to avoid unnecessary wakeups. Poor man's KCM using BPF
> sockmaps. Passing message size hints from the sender would solve so
> many problems..

Yes, RPC headers make things easier for sure.

(we internally have something similar named autolowat, where we parse
headers to set sk->sk_rcvlowat dynamically)