Re: [PATCH 0/2] net: Use synchronous wakeups selectively

[Srikar Dronamraju <srikar@linux.ibm.com>]

* Eric Dumazet <edumazet@google.com> [2026-07-23 10:57:24]:

> On Thu, Jul 23, 2026 at 10:50 AM Srikar Dronamraju <srikar@linux.ibm.com> wrote:
> >
> > * Eric Dumazet <edumazet@google.com> [2026-07-23 05:17:08]:
> >
> > > On Wed, Jul 22, 2026 at 7:08 PM Jakub Kicinski <kuba@kernel.org> wrote:
> > > >
> > > > On Tue, 14 Jul 2026 07:09:41 +0530 Srikar Dronamraju wrote:
> > > > > The scheduler assumes in several wakeup paths that a task using WF_SYNC
> > > > > is likely to yield the CPU shortly. However several networking wakeup
> > > > > paths unconditionally use synchronous wakeups even when the waking task
> > > > > continues execution.
> > >
> > > In any case, adding code to the fast path in every network system call
> > > is undesirable.
> >
> > Yes, I understand adding code in fast path is undesirable. However as
> > mentioned previous reply, we need to differentiate between blocking and
> > non-blocking API. Doing unconditional nonblocking, is probably even worse.
> 
> I suggested that applications choose what they prefer for each socket,
> once and for all.
> (This can also be a cgroup/BPF setting)
> 
> Flipping a socket bit at each recvmsg()/sendmsg() is a bad idea, you
> might break old application expectations.

Set once per socket is fine. However at the time of wake, we still have to
check the socket option right? I hope that overhead is fine.

Also do you have any precedent for once per socket option that I could look
at?

Thanks for your inputs.

-- 
Thanks and Regards
Srikar Dronamraju