Re: [PATCH net-next] net: shrink napi_skb_cache_put()

[Kuniyuki Iwashima <kuniyu@google.com>]

On Wed, Oct 15, 2025 at 4:38 PM Eric Dumazet <edumazet@google.com> wrote:
>
> Following loop in napi_skb_cache_put() is unrolled by the compiler
> even if CONFIG_KASAN is not enabled:
>
> for (i = NAPI_SKB_CACHE_HALF; i < NAPI_SKB_CACHE_SIZE; i++)
>         kasan_mempool_unpoison_object(nc->skb_cache[i],
>                                 kmem_cache_size(net_hotdata.skbuff_cache));
>
> We have 32 times this sequence, for a total of 384 bytes.
>
>         48 8b 3d 00 00 00 00    net_hotdata.skbuff_cache,%rdi
>         e8 00 00 00 00          call   kmem_cache_size
>
> This is because kmem_cache_size() is an extern function,
> and kasan_unpoison_object_data() is an inline function.
>
> Cache kmem_cache_size() result in a temporary variable, and
> make the loop conditional to CONFIG_KASAN.
>
> After this patch, napi_skb_cache_put() is inlined in its callers.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>

Oh exactly, it's interesting that the compiler cannot optimise out
unused retval even though kmem_cache_size() is a single load :o

$ grep KASAN .config
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_CC_HAS_KASAN_GENERIC=y
CONFIG_CC_HAS_KASAN_SW_TAGS=y
# CONFIG_KASAN is not set

$ objdump --disassemble=napi_skb_cache_put vmlinux
...
ffffffff81e9fe10 <napi_skb_cache_put>:
...
ffffffff81e9fe40: 48 8b 3d 89 bd d6 00 mov    0xd6bd89(%rip),%rdi
  # ffffffff82c0bbd0 <net_hotdata+0x150>
ffffffff81e9fe47: e8 a4 79 60 ff       call   ffffffff814a77f0 <kmem_cache_size>
ffffffff81e9fe4c: 83 eb 01             sub    $0x1,%ebx
ffffffff81e9fe4f: 75 ef                jne    ffffffff81e9fe40
<napi_skb_cache_put+0x30>