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: <CANn89iL=a922QTQUwr5EK6XeL+gQu-zeqca1PYhs-NBu3aeyzg@mail.gmail.com>
Date: Mon, 26 Jan 2026 09:45:06 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: "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 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?

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.

Thanks !