netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <edumazet@google.com>
Cc: <davem@davemloft.net>, <eric.dumazet@gmail.com>,
	<horms@kernel.org>, <kernelxing@tencent.com>, <kuba@kernel.org>,
	<kuniyu@amazon.com>, <ncardwell@google.com>,
	<netdev@vger.kernel.org>, <pabeni@redhat.com>
Subject: Re: [PATCH net-next 2/2] inet: call inet6_ehashfn() once from inet6_hash_connect()
Date: Wed, 5 Mar 2025 20:26:43 -0800	[thread overview]
Message-ID: <20250306042707.70115-1-kuniyu@amazon.com> (raw)
In-Reply-To: <20250305034550.879255-3-edumazet@google.com>

From: Eric Dumazet <edumazet@google.com>
Date: Wed,  5 Mar 2025 03:45:50 +0000
> inet6_ehashfn() being called from __inet6_check_established()
> has a big impact on performance, as shown in the Tested section.
> 
> After prior patch, we can compute the hash for port 0
> from inet6_hash_connect(), and derive each hash in
> __inet_hash_connect() from this initial hash:
> 
> hash(saddr, lport, daddr, dport) == hash(saddr, 0, daddr, dport) + lport
> 
> Apply the same principle for __inet_check_established(),
> although inet_ehashfn() has a smaller cost.
> 
> Tested:
> 
> Server: ulimit -n 40000; neper/tcp_crr -T 200 -F 30000 -6 --nolog
> Client: ulimit -n 40000; neper/tcp_crr -T 200 -F 30000 -6 --nolog -c -H server
> 
> Before this patch:
> 
>   utime_start=0.286131
>   utime_end=4.378886
>   stime_start=11.952556
>   stime_end=1991.655533
>   num_transactions=1446830
>   latency_min=0.001061085
>   latency_max=12.075275028
>   latency_mean=0.376375302
>   latency_stddev=1.361969596
>   num_samples=306383
>   throughput=151866.56
> 
> perf top:
> 
>  50.01%  [kernel]       [k] __inet6_check_established
>  20.65%  [kernel]       [k] __inet_hash_connect
>  15.81%  [kernel]       [k] inet6_ehashfn
>   2.92%  [kernel]       [k] rcu_all_qs
>   2.34%  [kernel]       [k] __cond_resched
>   0.50%  [kernel]       [k] _raw_spin_lock
>   0.34%  [kernel]       [k] sched_balance_trigger
>   0.24%  [kernel]       [k] queued_spin_lock_slowpath
> 
> After this patch:
> 
>   utime_start=0.315047
>   utime_end=9.257617
>   stime_start=7.041489
>   stime_end=1923.688387
>   num_transactions=3057968
>   latency_min=0.003041375
>   latency_max=7.056589232
>   latency_mean=0.141075048    # Better latency metrics
>   latency_stddev=0.526900516
>   num_samples=312996
>   throughput=320677.21        # 111 % increase, and 229 % for the series
> 
> perf top: inet6_ehashfn is no longer seen.
> 
>  39.67%  [kernel]       [k] __inet_hash_connect
>  37.06%  [kernel]       [k] __inet6_check_established
>   4.79%  [kernel]       [k] rcu_all_qs
>   3.82%  [kernel]       [k] __cond_resched
>   1.76%  [kernel]       [k] sched_balance_domains
>   0.82%  [kernel]       [k] _raw_spin_lock
>   0.81%  [kernel]       [k] sched_balance_rq
>   0.81%  [kernel]       [k] sched_balance_trigger
>   0.76%  [kernel]       [k] queued_spin_lock_slowpath
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

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

Interesting optimisation, thanks!

  reply	other threads:[~2025-03-06  4:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05  3:45 [PATCH net-next 0/2] tcp: even faster connect() under stress Eric Dumazet
2025-03-05  3:45 ` [PATCH net-next 1/2] inet: change lport contribution to inet_ehashfn() and inet6_ehashfn() Eric Dumazet
2025-03-06  4:24   ` Kuniyuki Iwashima
2025-03-06  7:54   ` Jason Xing
2025-03-06  8:14     ` Eric Dumazet
2025-03-06  8:19       ` Jason Xing
2025-03-17 13:44   ` kernel test robot
2025-03-05  3:45 ` [PATCH net-next 2/2] inet: call inet6_ehashfn() once from inet6_hash_connect() Eric Dumazet
2025-03-06  4:26   ` Kuniyuki Iwashima [this message]
2025-03-06  8:22   ` Jason Xing
2025-03-05  4:01 ` [PATCH net-next 0/2] tcp: even faster connect() under stress Eric Dumazet
2025-03-06 23:40 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250306042707.70115-1-kuniyu@amazon.com \
    --to=kuniyu@amazon.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=horms@kernel.org \
    --cc=kernelxing@tencent.com \
    --cc=kuba@kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).