public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Fernando Fernandez Mancera <fmancera@suse.de>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com, horms@kernel.org, corbet@lwn.net,
	ncardwell@google.com, kuniyu@google.com, dsahern@kernel.org,
	idosch@nvidia.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Thorsten Toepper <thorsten.toepper@sap.com>
Subject: Re: [PATCH RFC net-next] inet: add ip_retry_random_port sysctl to reduce sequential port retries
Date: Fri, 6 Feb 2026 17:27:48 +0100	[thread overview]
Message-ID: <1649583d-71c2-425e-a2df-685d5f6dc67d@suse.de> (raw)
In-Reply-To: <8d94faf9-2fb6-483d-9767-bd665c4a4b9a@suse.de>

On 2/4/26 6:29 PM, Fernando Fernandez Mancera wrote:
> On 2/4/26 5:49 PM, Eric Dumazet wrote:
>> On Tue, Feb 3, 2026 at 6:54 PM Fernando Fernandez Mancera
>> <fmancera@suse.de> wrote:
>>>
>>> With the current port selection algorithm, ports after a reserved port
>>> or long time used port are used more often than others. This combines
>>> with cloud environments blocking connections between the application
>>> server and the database server if there was a previous connection with
>>> the same source port. This leads to connectivity problems between
>>> applications on cloud environments.
>>>
>>> The situation is that a source tuple is usable again after being closed
>>> for a maximum lifetime segment of two minutes while in the firewall it's
>>> still noted as existing for 60 minutes or longer. So in case that the
>>> port is reused for the same target tuple before the firewall cleans up,
>>> the connection will fail due to firewall interference which itself will
>>> reset the activity timeout in its own table. We understand the real
>>> issue here is that these firewalls cannot cope with standards-compliant
>>> port reuse. But this is a workaround for such situations and an
>>> improvement on the distribution of ports selected.
>>>
>>> The proposed solution is instead of incrementing the port number,
>>> performing a re-selection of a new random port within the remaining
>>> range. This solution is configured via sysctl new option
>>> "net.ipv4.ip_retry_random_port".
>>>
>>> The test run consists of two processes, a client and a server, and loops
>>> connect to the server sending some bytes back. The results we got are
>>> promising:
>>>
>>> Executed test: Current algorithm
>>> ephemeral port range: 9000-65499
>>> simulated selections: 10000000
>>> retries during simulation: 14197718
>>> longest retry sequence: 5202
>>>
>>> Executed test: Proposed modified algorithm
>>> ephemeral port range: 9000-65499
>>> simulated selections: 10000000
>>> retries during simulation: 3976671
>>> longest retry sequence: 12
>>>
>>> In addition, on graphs generated we can observe that the distribution of
>>> source ports is more even with the proposed patch.
>>>
>>> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
>>> Tested-by: Thorsten Toepper <thorsten.toepper@sap.com>
>>> ---
>>>   .../networking/net_cachelines/netns_ipv4_sysctl.rst        | 1 +
>>>   include/net/netns/ipv4.h                                   | 1 +
>>>   net/ipv4/inet_hashtables.c                                 | 7 ++++++-
>>>   net/ipv4/sysctl_net_ipv4.c                                 | 7 +++++++
>>>   4 files changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/networking/net_cachelines/ 
>>> netns_ipv4_sysctl.rst b/Documentation/networking/net_cachelines/ 
>>> netns_ipv4_sysctl.rst
>>> index beaf1880a19b..c4041fdca01e 100644
>>> --- a/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
>>> +++ b/Documentation/networking/net_cachelines/netns_ipv4_sysctl.rst
>>> @@ -47,6 +47,7 @@ u8                              sysctl_tcp_ecn
>>>   u8                              sysctl_tcp_ecn_fallback
>>>   u8                              
>>> sysctl_ip_default_ttl                                                                ip4_dst_hoplimit/ip_select_ttl
>>>   u8                              sysctl_ip_no_pmtu_disc
>>> +u8                              sysctl_ip_retry_random_port
>>>   u8                              
>>> sysctl_ip_fwd_use_pmtu                       
>>> read_mostly                             ip_dst_mtu_maybe_forward/ 
>>> ip_skb_dst_mtu
>>>   u8                              
>>> sysctl_ip_fwd_update_priority                                                        ip_forward
>>>   u8                              sysctl_ip_nonlocal_bind
>>> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
>>> index 2dbd46fc4734..d04b07e7c935 100644
>>> --- a/include/net/netns/ipv4.h
>>> +++ b/include/net/netns/ipv4.h
>>> @@ -156,6 +156,7 @@ struct netns_ipv4 {
>>>
>>>          u8 sysctl_ip_default_ttl;
>>>          u8 sysctl_ip_no_pmtu_disc;
>>> +       u8 sysctl_ip_retry_random_port;
>>>          u8 sysctl_ip_fwd_update_priority;
>>>          u8 sysctl_ip_nonlocal_bind;
>>>          u8 sysctl_ip_autobind_reuse;
>>> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
>>> index f5826ec4bcaa..f1c79a7d3fd3 100644
>>> --- a/net/ipv4/inet_hashtables.c
>>> +++ b/net/ipv4/inet_hashtables.c
>>> @@ -1088,8 +1088,13 @@ int __inet_hash_connect(struct 
>>> inet_timewait_death_row *death_row,
>>>          for (i = 0; i < remaining; i += step, port += step) {
>>>                  if (unlikely(port >= high))
>>>                          port -= remaining;
>>> -               if (inet_is_local_reserved_port(net, port))
>>> +               if (inet_is_local_reserved_port(net, port)) {
>>> +                       if (net->ipv4.sysctl_ip_retry_random_port) {
>>> +                               port = low + 
>>> get_random_u32_below(remaining);
>>> +                               port = ((port & 1) == step) ? port : 
>>> (port - 1);
>>> +                       }
>>
>> What happens when almost  all ephemeral ports are in use, and
>> hundreds of ports are reserved ?
>>
>> Choosing a random value each time we meet a reserved port is going to
>> be quite expensive,
>> and we might return an error from this function even if there are many
>> available ports.
>>
>> Perhaps randomly select @step one time at the beginning of this
>> function so that  @step/2 and @remaining/2
>> are relatively prime numbers.
>>
> 
> That actually makes sense. It would ensure all ports are visited before 
> returning an error. Let me test this out.
> 

It makes sense. I have tested this approach and we got a more even 
distribution of source ports when having thousands of reserved ports. No 
difference at all when not using reserved ports.

Please, you can find the distribution graph with the current algorithm 
[1] and with the random step algorithm [2].

While I understand that this approach is introducing a call to 
get_random_u32_below() on every connect, I am wondering if it makes 
sense to replace the existing algorithm with this variant. What do you 
think?

Please, notice the implementation below. I plan to send an official v1 
once net-next is open. In addition, I am rewriting the commit message as 
I find the current one confusing.

[1] https://0xffsoftware.com/port_graph_current_alg.html

[2] https://0xffsoftware.com/port_graph_random_step_alg.html

Thanks,
Fernando.

diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index f5826ec4bcaa..10ecad190bae 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -16,6 +16,7 @@
  #include <linux/wait.h>
  #include <linux/vmalloc.h>
  #include <linux/memblock.h>
+#include <linux/gcd.h>

  #include <net/addrconf.h>
  #include <net/inet_connection_sock.h>
@@ -1046,11 +1047,11 @@ int __inet_hash_connect(struct 
inet_timewait_death_row *death_row,
  	struct net *net = sock_net(sk);
  	struct inet_bind2_bucket *tb2;
  	struct inet_bind_bucket *tb;
+	int step, scan_step, l3mdev;
  	bool tb_created = false;
  	u32 remaining, offset;
  	int ret, i, low, high;
  	bool local_ports;
-	int step, l3mdev;
  	u32 index;

  	if (port) {
@@ -1065,6 +1066,7 @@ int __inet_hash_connect(struct 
inet_timewait_death_row *death_row,

  	local_ports = inet_sk_get_local_port_range(sk, &low, &high);
  	step = local_ports ? 1 : 2;
+	scan_step = step;

  	high++; /* [32768, 60999] -> [32768, 61000[ */
  	remaining = high - low;
@@ -1083,9 +1085,20 @@ int __inet_hash_connect(struct 
inet_timewait_death_row *death_row,
  	 */
  	if (!local_ports)
  		offset &= ~1U;
+	if (net->ipv4.sysctl_ip_retry_random_port) {
+		u32 range = (step == 1) ? remaining : (remaining / 2);
+
+		scan_step = 1 + get_random_u32_below(range - 1);
+		while (gcd(scan_step, range) != 1) {
+			scan_step++;
+			if (unlikely(scan_step >= range))
+				scan_step = 1;
+		}
+		scan_step *= step;
+	}
  other_parity_scan:
  	port = low + offset;
-	for (i = 0; i < remaining; i += step, port += step) {
+	for (i = 0; i < remaining; i += step, port += scan_step) {
  		if (unlikely(port >= high))
  			port -= remaining;
  		if (inet_is_local_reserved_port(net, port))


> Thank you Eric,
> Fernando.
> 


  reply	other threads:[~2026-02-06 16:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 17:54 [PATCH RFC net-next] inet: add ip_retry_random_port sysctl to reduce sequential port retries Fernando Fernandez Mancera
2026-02-03 18:02 ` Fernando Fernandez Mancera
2026-02-04 16:25 ` Fernando Fernandez Mancera
2026-02-04 16:49 ` Eric Dumazet
2026-02-04 17:29   ` Fernando Fernandez Mancera
2026-02-06 16:27     ` Fernando Fernandez Mancera [this message]
2026-02-06 17:09       ` Eric Dumazet
2026-02-09 11:56         ` Fernando Fernandez Mancera
2026-02-09 13:53           ` longxie86
2026-02-09 15:25             ` Fernando Fernandez Mancera

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=1649583d-71c2-425e-a2df-685d5f6dc67d@suse.de \
    --to=fmancera@suse.de \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=thorsten.toepper@sap.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