netdev - Re: [PATCH net-next] tcp: move sk_forced_mem

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] [day] [month] [year] [list]

Message-ID: <CANn89iK60d+X0eRffN2jrJAON4DLsLH2Y+Yg5f+OOsr5mGGsNg@mail.gmail.com>
Date: Tue, 27 Jan 2026 03:06:36 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: Paolo Abeni <pabeni@...hat.com>, "David S . Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Simon Horman <horms@...nel.org>, 
	Kuniyuki Iwashima <kuniyu@...gle.com>, netdev@...r.kernel.org, eric.dumazet@...il.com, 
	Neal Cardwell <ncardwell@...gle.com>
Subject: Re: [PATCH net-next] tcp: move sk_forced_mem_schedule() to tcp.c

On Tue, Jan 27, 2026 at 2:56 AM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> Hi Eric,
>
> On Mon, Jan 26, 2026 at 4:45 PM Eric Dumazet <edumazet@...gle.com> wrote:
> >
> > On Mon, Jan 26, 2026 at 9:18 AM Paolo Abeni <pabeni@...hat.com> wrote:
> > >
> > > Hi Eric,
> > >
> > > On Fri, Jan 23, 2026 at 6:16 AM Eric Dumazet <edumazet@...gle.com> wrote:
> > > > TCP fast path can (auto)inline this helper, instead
> > >  of (auto)inling it from tcp_send_fin().
> > > >
> > > >> No change of overall code size, but tcp_sendmsg() is faster.
> > > >
> > > > $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new
> > > > add/remove: 0/0 grow/shrink: 1/1 up/down: 141/-140 (1)
> > > > Function                                     old     new   delta
> > > > tcp_stream_alloc_skb                         216     357    +141
> > > > tcp_send_fin                                 688     548    -140
> > > > Total: Before=22236729, After=22236730, chg +0.00%
> > > >
> > > > BTW, we might change tcp_send_fin() to use tcp_stream_alloc_skb().
> > > >
> > > > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > >
> > > I've a question out of sheer curiosity: are you using some specific tool
> > > to look for inline opportunity, or "just" careful code and/or objdump
> > > analysis?
>
> Paolo, right, you beat me to it! I'm also curious :)
>
> >
> > I am studying performance profiles on a stress test using Google
> > production kernels,
> > on platforms that are a big chunk of the fleet.
> > These kernels are very close to upstream (at least for core and TCP
> > networking stacks), and use clang and FDO.
> >
> > I am currently focusing on some functions that even FDO does not
> > inline, for some reasons.
>
> Eric, could you share your more valuable experience and methodology behind this?
>
> Prior to the recent work you've done, I completely missed that we
> could even do something with the inline functions. Normally using perf
> doesn't give us a clear micro observation of those functions
> especially about some hints on whether we should inline some
> functions. If there is any tool, it would be super awesome!
>

perf is your friend, and a deep knowledge of your cpu-du-jour behavior
(assembly)

perf record -C xxx -g sleep 10
perf report --no-children

<Use the perf UI appropriately>

> Let me guess, are you trying to avoid function call action as much as
> you can in the hot path based on your deep understanding of
> ingress/egress performance?

I think you could answer the question by parsing the changelogs of my
recent commits ;)