[PATCH net-next 0/2] nexthop: Support large scale nexthop flushing

From: Ido Schimmel <idosch@nvidia.com>

Patch #1 fixes a day-one bug in the nexthop code and allows "ip nexthop
flush" to work correctly with large number of nexthops that do not fit
in a single-part dump.

Patch #2 adds a test case.

Targeting at net-next since this use case never worked, the flow is
pretty obscure and such a large number of nexthops is unlikely to be
used in any real-world scenario.

Tested with fib_nexthops.sh:

Tests passed: 219
Tests failed:   0

Ido Schimmel (2):
  nexthop: Restart nexthop dump based on last dumped nexthop identifier
  selftests: fib_nexthops: Test large scale nexthop flushing

 net/ipv4/nexthop.c                          | 14 ++++++--------
 tools/testing/selftests/net/fib_nexthops.sh | 15 +++++++++++++++
 2 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.30.2

From: Ido Schimmel <idosch@nvidia.com>

Currently, a multi-part nexthop dump is restarted based on the number of
nexthops that have been dumped so far. This can result in a lot of
nexthops not being dumped when nexthops are simultaneously deleted:

 # ip nexthop | wc -l
 65536
 # ip nexthop flush
 Dump was interrupted and may be inconsistent.
 Flushed 36040 nexthops
 # ip nexthop | wc -l
 29496

Instead, restart the dump based on the nexthop identifier (fixed number)
of the last successfully dumped nexthop:

 # ip nexthop | wc -l
 65536
 # ip nexthop flush
 Dump was interrupted and may be inconsistent.
 Flushed 65536 nexthops
 # ip nexthop | wc -l
 0

Reported-by: Maksym Yaremchuk <redacted>
Tested-by: Maksym Yaremchuk <redacted>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
 net/ipv4/nexthop.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index 5a2fc8798d20..4075230b14c6 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c

@@ -3140,26 +3140,24 @@ static int rtm_dump_walk_nexthops(struct sk_buff *skb,
 				  void *data)
 {
 	struct rb_node *node;
-	int idx = 0, s_idx;
+	int s_idx;
 	int err;
 
 	s_idx = ctx->idx;
 	for (node = rb_first(root); node; node = rb_next(node)) {
 		struct nexthop *nh;
 
-		if (idx < s_idx)
-			goto cont;
-
 		nh = rb_entry(node, struct nexthop, rb_node);
-		ctx->idx = idx;
+		if (nh->id < s_idx)
+			continue;
+
+		ctx->idx = nh->id;
 		err = nh_cb(skb, cb, nh, data);
 		if (err)
 			return err;
-cont:
-		idx++;
 	}
 
-	ctx->idx = idx;
+	ctx->idx++;
 	return 0;
 }
 

-- 
2.30.2

From: Ido Schimmel <idosch@nvidia.com>

Test that all the nexthops are flushed when a multi-part nexthop dump is
required for the flushing.

Without previous patch:

 # ./fib_nexthops.sh
 TEST: Large scale nexthop flushing                                  [FAIL]

With previous patch:

 # ./fib_nexthops.sh
 TEST: Large scale nexthop flushing                                  [ OK ]

Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
 tools/testing/selftests/net/fib_nexthops.sh | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
index 56dd0c6f2e96..49774a8a7736 100755
--- a/tools/testing/selftests/net/fib_nexthops.sh
+++ b/tools/testing/selftests/net/fib_nexthops.sh

@@ -1933,6 +1933,21 @@ basic()
 	log_test $? 2 "Nexthop group and blackhole"
 
 	$IP nexthop flush >/dev/null 2>&1
+
+	# Test to ensure that flushing with a multi-part nexthop dump works as
+	# expected.
+	local batch_file=$(mktemp)
+
+	for i in $(seq 1 $((64 * 1024))); do
+		echo "nexthop add id $i blackhole" >> $batch_file
+	done
+
+	$IP -b $batch_file
+	$IP nexthop flush >/dev/null 2>&1
+	[[ $($IP nexthop | wc -l) -eq 0 ]]
+	log_test $? 0 "Large scale nexthop flushing"
+
+	rm $batch_file
 }
 
 check_nexthop_buckets_balance()

-- 
2.30.2

On 4/16/21 8:55 AM, Ido Schimmel wrote:

From: Ido Schimmel <idosch@nvidia.com>

Currently, a multi-part nexthop dump is restarted based on the number of
nexthops that have been dumped so far. This can result in a lot of
nexthops not being dumped when nexthops are simultaneously deleted:

 # ip nexthop | wc -l
 65536
 # ip nexthop flush
 Dump was interrupted and may be inconsistent.
 Flushed 36040 nexthops
 # ip nexthop | wc -l
 29496

Instead, restart the dump based on the nexthop identifier (fixed number)
of the last successfully dumped nexthop:

 # ip nexthop | wc -l
 65536
 # ip nexthop flush
 Dump was interrupted and may be inconsistent.
 Flushed 65536 nexthops
 # ip nexthop | wc -l
 0

Reported-by: Maksym Yaremchuk <redacted>
Tested-by: Maksym Yaremchuk <redacted>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
 net/ipv4/nexthop.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

Reviewed-by: David Ahern <dsahern@kernel.org>

Any reason not to put this in -net with a Fixes tag?

On 4/16/21 8:55 AM, Ido Schimmel wrote:

From: Ido Schimmel <idosch@nvidia.com>

Test that all the nexthops are flushed when a multi-part nexthop dump is
required for the flushing.

Without previous patch:

 # ./fib_nexthops.sh
 TEST: Large scale nexthop flushing                                  [FAIL]

With previous patch:

 # ./fib_nexthops.sh
 TEST: Large scale nexthop flushing                                  [ OK ]

Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
 tools/testing/selftests/net/fib_nexthops.sh | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

Reviewed-by: David Ahern <dsahern@kernel.org>

On Sun, Apr 18, 2021 at 10:06:41AM -0700, David Ahern wrote:

On 4/16/21 8:55 AM, Ido Schimmel wrote:

quoted

From: Ido Schimmel <idosch@nvidia.com>

Currently, a multi-part nexthop dump is restarted based on the number of
nexthops that have been dumped so far. This can result in a lot of
nexthops not being dumped when nexthops are simultaneously deleted:

 # ip nexthop | wc -l
 65536
 # ip nexthop flush
 Dump was interrupted and may be inconsistent.
 Flushed 36040 nexthops
 # ip nexthop | wc -l
 29496

Instead, restart the dump based on the nexthop identifier (fixed number)
of the last successfully dumped nexthop:

 # ip nexthop | wc -l
 65536
 # ip nexthop flush
 Dump was interrupted and may be inconsistent.
 Flushed 65536 nexthops
 # ip nexthop | wc -l
 0

Reported-by: Maksym Yaremchuk <redacted>
Tested-by: Maksym Yaremchuk <redacted>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
---
 net/ipv4/nexthop.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

Reviewed-by: David Ahern <dsahern@kernel.org>

Thanks

Any reason not to put this in -net with a Fixes tag?

I put it in the cover letter:

"Targeting at net-next since this use case never worked, the flow is
pretty obscure and such a large number of nexthops is unlikely to be
used in any real-world scenario."

Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Fri, 16 Apr 2021 18:55:33 +0300 you wrote:

From: Ido Schimmel <idosch@nvidia.com>

Patch #1 fixes a day-one bug in the nexthop code and allows "ip nexthop
flush" to work correctly with large number of nexthops that do not fit
in a single-part dump.

Patch #2 adds a test case.

[...]

Here is the summary with links:
  - [net-next,1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier
    https://git.kernel.org/netdev/net-next/c/9e46fb656fdb
  - [net-next,2/2] selftests: fib_nexthops: Test large scale nexthop flushing
    https://git.kernel.org/netdev/net-next/c/bf5eb67dc80a

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html