* [PATCH net-next 0/2] nexthop: Support large scale nexthop flushing
@ 2021-04-16 15:55 Ido Schimmel
2021-04-16 15:55 ` [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier Ido Schimmel
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Ido Schimmel @ 2021-04-16 15:55 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, dsahern, petrm, mlxsw, Ido Schimmel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier
2021-04-16 15:55 [PATCH net-next 0/2] nexthop: Support large scale nexthop flushing Ido Schimmel
@ 2021-04-16 15:55 ` Ido Schimmel
2021-04-18 17:06 ` David Ahern
2021-04-16 15:55 ` [PATCH net-next 2/2] selftests: fib_nexthops: Test large scale nexthop flushing Ido Schimmel
2021-04-19 22:30 ` [PATCH net-next 0/2] nexthop: Support " patchwork-bot+netdevbpf
2 siblings, 1 reply; 7+ messages in thread
From: Ido Schimmel @ 2021-04-16 15:55 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, dsahern, petrm, mlxsw, Ido Schimmel
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 <maksymy@nvidia.com>
Tested-by: Maksym Yaremchuk <maksymy@nvidia.com>
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH net-next 2/2] selftests: fib_nexthops: Test large scale nexthop flushing
2021-04-16 15:55 [PATCH net-next 0/2] nexthop: Support large scale nexthop flushing Ido Schimmel
2021-04-16 15:55 ` [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier Ido Schimmel
@ 2021-04-16 15:55 ` Ido Schimmel
2021-04-18 17:07 ` David Ahern
2021-04-19 22:30 ` [PATCH net-next 0/2] nexthop: Support " patchwork-bot+netdevbpf
2 siblings, 1 reply; 7+ messages in thread
From: Ido Schimmel @ 2021-04-16 15:55 UTC (permalink / raw)
To: netdev; +Cc: davem, kuba, dsahern, petrm, mlxsw, Ido Schimmel
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier
2021-04-16 15:55 ` [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier Ido Schimmel
@ 2021-04-18 17:06 ` David Ahern
2021-04-19 5:48 ` Ido Schimmel
0 siblings, 1 reply; 7+ messages in thread
From: David Ahern @ 2021-04-18 17:06 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, kuba, petrm, mlxsw, Ido Schimmel
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 <maksymy@nvidia.com>
> Tested-by: Maksym Yaremchuk <maksymy@nvidia.com>
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH net-next 2/2] selftests: fib_nexthops: Test large scale nexthop flushing
2021-04-16 15:55 ` [PATCH net-next 2/2] selftests: fib_nexthops: Test large scale nexthop flushing Ido Schimmel
@ 2021-04-18 17:07 ` David Ahern
0 siblings, 0 replies; 7+ messages in thread
From: David Ahern @ 2021-04-18 17:07 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, kuba, petrm, mlxsw, Ido Schimmel
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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier
2021-04-18 17:06 ` David Ahern
@ 2021-04-19 5:48 ` Ido Schimmel
0 siblings, 0 replies; 7+ messages in thread
From: Ido Schimmel @ 2021-04-19 5:48 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, davem, kuba, petrm, mlxsw, Ido Schimmel
On Sun, Apr 18, 2021 at 10:06:41AM -0700, David Ahern wrote:
> 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 <maksymy@nvidia.com>
> > Tested-by: Maksym Yaremchuk <maksymy@nvidia.com>
> > 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."
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH net-next 0/2] nexthop: Support large scale nexthop flushing
2021-04-16 15:55 [PATCH net-next 0/2] nexthop: Support large scale nexthop flushing Ido Schimmel
2021-04-16 15:55 ` [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier Ido Schimmel
2021-04-16 15:55 ` [PATCH net-next 2/2] selftests: fib_nexthops: Test large scale nexthop flushing Ido Schimmel
@ 2021-04-19 22:30 ` patchwork-bot+netdevbpf
2 siblings, 0 replies; 7+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-04-19 22:30 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, kuba, dsahern, petrm, mlxsw, idosch
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-04-19 22:30 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-16 15:55 [PATCH net-next 0/2] nexthop: Support large scale nexthop flushing Ido Schimmel
2021-04-16 15:55 ` [PATCH net-next 1/2] nexthop: Restart nexthop dump based on last dumped nexthop identifier Ido Schimmel
2021-04-18 17:06 ` David Ahern
2021-04-19 5:48 ` Ido Schimmel
2021-04-16 15:55 ` [PATCH net-next 2/2] selftests: fib_nexthops: Test large scale nexthop flushing Ido Schimmel
2021-04-18 17:07 ` David Ahern
2021-04-19 22:30 ` [PATCH net-next 0/2] nexthop: Support " patchwork-bot+netdevbpf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.