Re: [PATCH bpf-next v4 0/3] add batched ops for percpu array

2021-04-19 Thread Brian Vazquez
Sorry I missed this. I don't recall why I didn't add the array percpu variant, but LGTM. Acked-by: Brian Vazquez On Fri, Apr 16, 2021 at 3:09 PM Martin KaFai Lau wrote: > > On Thu, Apr 15, 2021 at 02:46:16PM -0300, Pedro Tammela wrote: > > This patchset introduces batche

[PATCH net-next 1/2] net: add EXPORT_INDIRECT_CALLABLE wrapper

2021-02-04 Thread Brian Vazquez
introduces a new indirect call wrapper: EXPORT_INDIRECT_CALLABLE. This basically does EXPORT_SYMBOL when CONFIG_RETPOLINE is set, but does nothing when it's not. Reported-by: Stephen Rothwell Signed-off-by: Brian Vazquez --- include/linux/indirect_call_wrapper.h | 2 ++ 1 file changed, 2

[PATCH net-next 2/2] net: fix building errors on powerpc when CONFIG_RETPOLINE is not set

2021-02-04 Thread Brian Vazquez
MBOL ERROR: modpost: "ip6_mtu" [vmlinux] is a static EXPORT_SYMBOL Fixes: f67fbeaebdc0 ("net: use indirect call helpers for dst_mtu") Fixes: bbd807dfbf20 ("net: indirect call helpers for ipv4/ipv6 dst_check functions") Reported-by: Stephen Rothwell Signed-off-by: Bri

[PATCH net-next 2/2] net: fix building errors on powerpc when CONFIG_RETPOLINE is not set

2021-02-04 Thread Brian Vazquez
MBOL ERROR: modpost: "ip6_mtu" [vmlinux] is a static EXPORT_SYMBOL Fixes: f67fbeaebdc0 ("net: use indirect call helpers for dst_mtu") Fixes: bbd807dfbf20 ("net: indirect call helpers for ipv4/ipv6 dst_check functions") Reported-by: Stephen Rothwell Signed-off-by: Bri

Re: [PATCH net-next 1/2] net: add EXPORT_INDIRECT_CALLABLE wrapper

2021-02-04 Thread Brian Vazquez
Yeah, I'm also not seeing it on patchwork. But I did get the email on both corp and personal email. So maybe something is failing at patchwork? On Thu, Feb 4, 2021 at 9:50 AM George McCollister wrote: > > I don't see the second patch. > > Regards, > George McCollister

Re: linux-next: build failure after merge of the net-next tree

2021-02-04 Thread Brian Vazquez
Hi all, I've just sent the patch series: https://patchwork.kernel.org/project/netdevbpf/list/?series=428099. Thanks, Brian On Thu, Feb 4, 2021 at 7:36 AM Vladimir Oltean wrote: > > Hi Brian, > > On Wed, Feb 03, 2021 at 07:52:08PM -0800, Brian Vazquez wrote: > > Hi Stephen, tha

[PATCH net-next 1/2] net: add EXPORT_INDIRECT_CALLABLE wrapper

2021-02-04 Thread Brian Vazquez
introduces a new indirect call wrapper: EXPORT_INDIRECT_CALLABLE. This basically does EXPORT_SYMBOL when CONFIG_RETPOLINE is set, but does nothing when it's not. Reported-by: Stephen Rothwell Signed-off-by: Brian Vazquez --- include/linux/indirect_call_wrapper.h | 2 ++ 1 file changed, 2

Re: linux-next: build failure after merge of the net-next tree

2021-02-03 Thread Brian Vazquez
Hi Stephen, thanks for the report. I'm having trouble trying to compile for ppc, but I believe this should fix the problem, could you test this patch, please? Thanks! diff --git a/include/linux/indirect_call_wrapper.h b/include/linux/indirect_call_wrapper.h index 54c02c84906a..077f96be65c6 100644

[PATCH net-next v3 2/4] net: use indirect call helpers for dst_output

2021-02-01 Thread Brian Vazquez
This patch avoids the indirect call for the common case: ip6_output and ip_output Signed-off-by: Brian Vazquez --- include/net/dst.h | 8 +++- net/ipv4/ip_output.c | 1 + net/ipv6/ip6_output.c | 1 + 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/include/net/dst.h b

[PATCH net-next v3 3/4] net: use indirect call helpers for dst_mtu

2021-02-01 Thread Brian Vazquez
This patch avoids the indirect call for the common case: ip6_mtu and ipv4_mtu Signed-off-by: Brian Vazquez --- include/net/dst.h | 4 +++- net/ipv4/route.c | 6 -- net/ipv6/route.c | 6 -- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/include/net/dst.h b/include/net

[PATCH net-next v3 4/4] net: indirect call helpers for ipv4/ipv6 dst_check functions

2021-02-01 Thread Brian Vazquez
This patch avoids the indirect call for the common case: ip6_dst_check and ipv4_dst_check Signed-off-by: Brian Vazquez --- include/net/dst.h | 7 ++- net/core/sock.c | 12 ++-- net/ipv4/route.c| 7 +-- net/ipv4/tcp_ipv4.c | 5 - net/ipv6/route.c| 7

[PATCH net-next v3 0/4] net: use INDIRECT_CALL in some dst_ops

2021-02-01 Thread Brian Vazquez
06e-09 No difference proven at 80.0% confidence Changed in v3: - fix From: tag - provide measurements Changed in v2: -fix build issues reported by kernel test robot Brian Vazquez (4): net: use indirect call helpers for dst_input net: use indirect call helpers for dst_output net: use i

[PATCH net-next v3 1/4] net: use indirect call helpers for dst_input

2021-02-01 Thread Brian Vazquez
This patch avoids the indirect call for the common case: ip_local_deliver and ip6_input Signed-off-by: Brian Vazquez --- include/net/dst.h | 6 +- net/ipv4/ip_input.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/include/net/dst.h b/include/net/dst.h index

[PATCH net-next v2 4/4] net: indirect call helpers for ipv4/ipv6 dst_check functions

2020-12-11 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip6_dst_check and ipv4_dst_check Signed-off-by: brianvv --- include/net/dst.h | 7 ++- net/core/sock.c | 12 ++-- net/ipv4/route.c| 7 +-- net/ipv4/tcp_ipv4.c | 5 - net/ipv6/route.c|

[PATCH net-next v2 3/4] net: use indirect call helpers for dst_mtu

2020-12-11 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip6_mtu and ipv4_mtu Signed-off-by: brianvv --- include/net/dst.h | 4 +++- net/ipv4/route.c | 6 -- net/ipv6/route.c | 6 -- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/include/net/dst.h

[PATCH net-next v2 1/4] net: use indirect call helpers for dst_input

2020-12-11 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip_local_deliver and ip6_input Signed-off-by: brianvv --- include/net/dst.h | 6 +- net/ipv4/ip_input.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/include/net/dst.h b/include/net/dst.h index

[PATCH net-next v2 2/4] net: use indirect call helpers for dst_output

2020-12-11 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip6_output and ip_output Signed-off-by: brianvv --- include/net/dst.h | 8 +++- net/ipv4/ip_output.c | 1 + net/ipv6/ip6_output.c | 1 + 3 files changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH net-next v2 0/4] net: avoid indirect calls in dst functions

2020-12-11 Thread Brian Vazquez
From: brianvv Use of the indirect call wrappers in some dst related functions for the ipv6/ipv4 case. This is a small improvent for CONFIG_RETPOLINE=y Changed in v2: -fix build issues reported by kernel test robot brianvv (4): net: use indirect call helpers for dst_input net: use indirect

[PATCH net-next 3/4] net: use indirect call helpers for dst_mtu

2020-12-10 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip6_mtu and ipv4_mtu Signed-off-by: brianvv --- include/net/dst.h | 4 +++- net/ipv4/route.c | 6 -- net/ipv6/route.c | 6 -- 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/include/net/dst.h

[PATCH net-next 2/4] net: use indirect call helpers for dst_output

2020-12-10 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip6_output and ip_output Signed-off-by: brianvv --- include/net/dst.h | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/net/dst.h b/include/net/dst.h index 98cf6e8c06c4..3932e9931f08 100644

[PATCH net-next 4/4] net: indirect call helpers for ipv4/ipv6 dst_check functions

2020-12-10 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip6_dst_check and ipv4_dst_check Signed-off-by: brianvv --- include/net/dst.h | 7 ++- net/core/sock.c | 12 ++-- net/ipv4/route.c| 6 -- net/ipv4/tcp_ipv4.c | 5 - net/ipv6/route.c| 6

[PATCH net-next 0/4] net: avoid indirect calls in dst functions

2020-12-10 Thread Brian Vazquez
From: brianvv Use of the indirect call wrappers in some dst related functions for the ipv6/ipv4 case. This is a small improvent for CONFIG_RETPOLINE=y brianvv (4): net: use indirect call helpers for dst_input net: use indirect call helpers for dst_output net: use indirect call helpers for

[PATCH net-next 1/4] net: use indirect call helpers for dst_input

2020-12-10 Thread Brian Vazquez
From: brianvv This patch avoids the indirect call for the common case: ip_local_deliver and ip6_input Signed-off-by: brianvv --- include/net/dst.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/net/dst.h b/include/net/dst.h index 10f0a8399867..98cf6e8c06c4

[PATCH] fib: fix fib_rule_ops indirect call wrappers when CONFIG_IPV6=m

2020-09-08 Thread Brian Vazquez
] Error 1 Reported-by: Sven Joachim Fixes: b9aaec8f0be5 ("fib: use indirect call wrappers in the most common fib_rules_ops") Acked-by: Randy Dunlap # build-tested Signed-off-by: Brian Vazquez --- net/core/fib_rules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2] fib: fix fib_rule_ops indirect call wrappers when CONFIG_IPV6=m

2020-09-08 Thread Brian Vazquez
] Error 1 Reported-by: Sven Joachim Fixes: 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") Acked-by: Randy Dunlap # build-tested Signed-off-by: Brian Vazquez --- v2: -amend fixes tag to the right one net/core/fib_rules.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [PATCH] net: ipv6: fix __rt6_purge_dflt_routers when forwarding is not set on all ifaces

2020-09-01 Thread Brian Vazquez
On Tue, Sep 1, 2020 at 12:56 AM Eric Dumazet wrote: > > On Tue, Sep 1, 2020 at 8:58 AM Brian Vazquez wrote: > > > > The problem is exposed when the system has multiple ifaces and > > forwarding is enabled on a subset of them, __rt6_purge_dflt_routers will > >

Re: [PATCH] net: ipv6: fix __rt6_purge_dflt_routers when forwarding is not set on all ifaces

2020-09-01 Thread Brian Vazquez
On Tue, Sep 1, 2020 at 1:20 AM Eric Dumazet wrote: > > On Tue, Sep 1, 2020 at 8:58 AM Brian Vazquez wrote: > > > > The problem is exposed when the system has multiple ifaces and > > forwarding is enabled on a subset of them, __rt6_purge_dflt_routers will > >

Re: [PATCH] net: ipv6: fix __rt6_purge_dflt_routers when forwarding is not set on all ifaces

2020-09-01 Thread Brian Vazquez
Hey David, On Tue, Sep 1, 2020 at 7:57 AM David Ahern wrote: > > On 9/1/20 1:56 AM, Eric Dumazet wrote: > > On Tue, Sep 1, 2020 at 8:58 AM Brian Vazquez wrote: > >> > >> The problem is exposed when the system has multiple ifaces and > >> fo

[PATCH] net: ipv6: fix __rt6_purge_dflt_routers when forwarding is not set on all ifaces

2020-09-01 Thread Brian Vazquez
. Fixes: 830218c1add1 ("net: ipv6: Fix processing of RAs in presence of VRF") Cc: David Ahern Signed-off-by: Brian Vazquez --- net/ipv6/route.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 5e7e25e2523a..41181cd48

Re: linux-next: build failure after merge of the net-next tree

2020-08-28 Thread Brian Vazquez
On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap wrote: > > On 8/28/20 8:09 AM, Sven Joachim wrote: > > On 2020-08-27 11:12 -0700, Brian Vazquez wrote: > > > >> I've been trying to reproduce it with your config but I didn't > >> succeed. I also looke

Re: linux-next: build failure after merge of the net-next tree

2020-08-27 Thread Brian Vazquez
oachim wrote: > > > On 2020-08-21 09:23 -0700, Brian Vazquez wrote: > > > >> Hi Sven, > >> > >> Sorry for the late reply, did you still see this after: > >> https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaib...@huawei.com/ > &

Re: [PATCH net-next] fib: Fix undef compile warning

2020-08-03 Thread Brian Vazquez
Acked-By: Brian Vazquez On Mon, Aug 3, 2020 at 6:20 AM YueHaibing wrote: > > net/core/fib_rules.c:26:7: warning: "CONFIG_IP_MULTIPLE_TABLES" is not > defined, evaluates to 0 [-Wundef] > #elif CONFIG_IP_MULTIPLE_TABLES >^ > >

Re: [PATCH bpf-next] bpf: make __htab_lookup_and_delete_batch faster when map is almost empty

2020-08-01 Thread Brian Vazquez
On Sat, Aug 1, 2020 at 9:59 AM Yonghong Song wrote: > > > > On 7/31/20 9:57 PM, Brian Vazquez wrote: > > While running some experiments it was observed that map_lookup_batch was > > much > > slower than get_next_key + lookup when the syscall overhead is

[PATCH V2 bpf-next] bpf: make __htab_lookup_and_delete_batch faster when map is almost empty

2020-08-01 Thread Brian Vazquez
/1/64k58870 58674 1 [1] https://github.com/google/benchmark.git Changelog: v1 -> v2: - Add more information about how to interpret the results Suggested-by: Luigi Rizzo Cc: Yonghong Song Signed-off-by: Brian Vazquez --- kernel/bpf/hashtab.c |

[PATCH bpf-next] bpf: make __htab_lookup_and_delete_batch faster when map is almost empty

2020-07-31 Thread Brian Vazquez
BM_DumpHashMap/1/4k 5318 5316 10 BM_DumpHashMap/1/16k14925 14895 47448 BM_DumpHashMap/1/64k58870 58674 1 Suggested-by: Luigi Rizzo Cc: Yonghong Song Signed-off-by: Brian Vazquez --- kernel/bpf/hashtab.c | 23

Re: linux-next: Tree for Jul 31 (net/decnet/ & FIB_RULES)

2020-07-31 Thread Brian Vazquez
Ugh I completely missed CONFIG_IP_MULTIPLE_TABLES too, I sent the new patch. This time I believe I cover all the cases. PTAL. Thanks, Brian On Fri, Jul 31, 2020 at 5:50 PM Randy Dunlap wrote: > > On 7/31/20 5:35 PM, Stephen Rothwell wrote: > > Hi Randy, > > > > On Fri, 31 Jul 2020 08:53:09

[PATCH net-next] fib: fix another fib_rules_ops indirect call wrapper problem

2020-07-31 Thread Brian Vazquez
Rothwell Signed-off-by: Brian Vazquez --- net/core/fib_rules.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c index fce645f6b9b10..a7a3f500a857b 100644 --- a/net/core/fib_rules.c +++ b/net/core/fib_rules.c @@ -17,10 +17,16 @@

Re: linux-next: build failure after merge of the net-next tree

2020-07-29 Thread Brian Vazquez
Hi Stephen, thanks for reaching out and reporting the issue. I have just sent the fix for review in net-next: http://patchwork.ozlabs.org/project/netdev/patch/20200729181018.3221288-1-bria...@google.com/ cheers, Brian On Wed, Jul 29, 2020 at 4:27 AM Stephen Rothwell wrote: > > Hi all, > > After

[PATCH net-next] fib: fix fib_rules_ops indirect calls wrappers

2020-07-29 Thread Brian Vazquez
the most common fib_rules_ops") Signed-off-by: Brian Vazquez --- net/core/fib_rules.c | 33 - 1 file changed, 20 insertions(+), 13 deletions(-) diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c index e7a8f87b0bb2b..fce645f6b9b10 100644 --- a/net/core/fib_ru

[PATCH V2 net-next] fib: use indirect call wrappers in the most common fib_rules_ops

2020-07-26 Thread Brian Vazquez
This avoids another inderect call per RX packet which save us around 20-40 ns. Changelog: v1 -> v2: - Move declaraions to fib_rules.h to remove warnings Reported-by: kernel test robot Signed-off-by: Brian Vazquez --- include/net/fib_rules.h | 18 ++ net/core/fib_rule

[PATCH net-next] fib: use indirect call wrappers in the most common fib_rules_ops

2020-07-24 Thread Brian Vazquez
This avoids another inderect call per RX packet which save us around 20-40 ns. Signed-off-by: Brian Vazquez --- net/core/fib_rules.c | 32 net/ipv4/fib_rules.c | 12 net/ipv6/fib6_rules.c | 12 3 files changed, 44 insertions(+), 12

[PATCH v2 net-next 1/2] indirect_call_wrapper: extend indirect wrapper to support up to 4 calls

2020-06-23 Thread Brian Vazquez
There are many places where 2 annotations are not enough. This patch adds INDIRECT_CALL_3 and INDIRECT_CALL_4 to cover such cases. Signed-off-by: Brian Vazquez --- include/linux/indirect_call_wrapper.h | 12 1 file changed, 12 insertions(+) diff --git a/include/linux

[PATCH v2 net-next 2/2] ipv6: fib6: avoid indirect calls from fib6_rule_lookup

2020-06-23 Thread Brian Vazquez
Rizzo Cc: Paolo Abeni Reported-by: Eric Dumazet Signed-off-by: Brian Vazquez --- include/net/ip6_fib.h | 36 net/ipv6/fib6_rules.c | 9 ++--- net/ipv6/ip6_fib.c| 3 ++- net/ipv6/route.c | 8 4 files changed, 48 insertions(+), 8

[PATCH net-next 1/2] indirect_call_wrapper: extend indirect wrapper to support up to 4 calls

2020-06-19 Thread Brian Vazquez
There are many places where 2 annotations are not enough. This patch adds INDIRECT_CALL_3 and INDIRECT_CALL_4 to cover such cases. Signed-off-by: Brian Vazquez --- include/linux/indirect_call_wrapper.h | 12 1 file changed, 12 insertions(+) diff --git a/include/linux

[PATCH net-next 2/2] ipv6: fib6: avoid indirect calls from fib6_rule_lookup

2020-06-19 Thread Brian Vazquez
36018950.0 Without the patch the average is 354263 pkt/s or 2822 ns/pkt and with the patch the average is 360738 pkt/s or 2772 ns/pkt which gives an estimate of 50 ns per packet. [1] http://netsniff-ng.org/ Reported-by: Eric Dumazet Signed-off-by: Brian Vazquez Cc: Luigi Rizzo

Re: [PATCH bpf 2/2] selftests/bpf: test_progs: don't leak server_fd in test_sockopt_inherit

2019-10-01 Thread Brian Vazquez
Thanks for reviewing the patches Andrii! Although Daniel fixed them and applied them correctly. On Tue, Oct 1, 2019 at 8:20 PM Andrii Nakryiko wrote: > > On Tue, Oct 1, 2019 at 10:40 AM Brian Vazquez wrote: > > > > I don't think there is a need to add "

[PATCH bpf 2/2] selftests/bpf: test_progs: don't leak server_fd in test_sockopt_inherit

2019-10-01 Thread Brian Vazquez
server_fd needs to be close if pthread can't be created. Fixes: e3e02e1d9c24 ("selftests/bpf: test_progs: convert test_sockopt_inherit") Cc: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/prog_tests/sockopt_inherit.c | 2 +- 1 file changed, 1 inser

[PATCH bpf 1/2] selftests/bpf: test_progs: don't leak server_fd in tcp_rtt

2019-10-01 Thread Brian Vazquez
server_fd needs to be closed if pthread can't be created. Fixes: 8a03222f508b ("selftests/bpf: test_progs: fix client/server race in tcp_rtt") Cc: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/prog_tests/tcp_rtt.c | 3 ++- 1 file changed, 2 insert

[PATCH bpf 0/2] selftests/bpf: test_progs: don't leak fd in bpf

2019-10-01 Thread Brian Vazquez
This patch series fixes some fd leaks in tcp_rtt and test_sockopt_inherit bpf prof_tests. Brian Vazquez (2): selftests/bpf: test_progs: don't leak server_fd in tcp_rtt selftests/bpf: test_progs: don't leak server_fd in test_sockopt_inherit tools/testing/selftests/bpf/prog_tests

Re: [PATCH bpf-next 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-25 Thread Brian Vazquez
On Thu, Jul 25, 2019 at 4:54 PM Alexei Starovoitov wrote: > > On Thu, Jul 25, 2019 at 04:25:53PM -0700, Brian Vazquez wrote: > > > > > If prev_key is deleted before map_get_next_key(), we get the first key > > > > > again. This is pretty weird. &

Re: [PATCH bpf-next 3/6] bpf: keep bpf.h in sync with tools/

2019-07-25 Thread Brian Vazquez
On Wed, Jul 24, 2019 at 4:10 PM Andrii Nakryiko wrote: > > On Wed, Jul 24, 2019 at 10:10 AM Brian Vazquez wrote: > > > > Adds bpf_attr.dump structure to libbpf. > > > > Suggested-by: Stanislav Fomichev > > Signed-off-by: Brian Vazquez > > -

Re: [PATCH bpf-next 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-25 Thread Brian Vazquez
> > > If prev_key is deleted before map_get_next_key(), we get the first key > > > again. This is pretty weird. > > > > Yes, I know. But note that the current scenario happens even for the > > old interface (imagine you are walking a map from userspace and you > > tried get_next_key the prev_key

Re: [PATCH bpf-next 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-24 Thread Brian Vazquez
On Wed, Jul 24, 2019 at 2:40 PM Song Liu wrote: > > On Wed, Jul 24, 2019 at 10:10 AM Brian Vazquez wrote: > > > > This introduces a new command to retrieve multiple number of entries > > from a bpf map, wrapping the existing bpf methods: > > map_get_next_key and ma

Re: [PATCH bpf-next 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-24 Thread Brian Vazquez
On Wed, Jul 24, 2019 at 12:55 PM Willem de Bruijn wrote: > > On Wed, Jul 24, 2019 at 1:10 PM Brian Vazquez wrote: > > > > This introduces a new command to retrieve multiple number of entries > > from a bpf map, wrapping the existing bpf methods: > > map_ge

Re: [PATCH bpf-next 0/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-24 Thread Brian Vazquez
On Wed, Jul 24, 2019 at 12:20 PM Song Liu wrote: > > On Wed, Jul 24, 2019 at 10:09 AM Brian Vazquez wrote: > > > > This introduces a new command to retrieve multiple number of entries > > from a bpf map. > > > > This new command can be executed from the

[PATCH bpf-next 3/6] bpf: keep bpf.h in sync with tools/

2019-07-24 Thread Brian Vazquez
Adds bpf_attr.dump structure to libbpf. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/include/uapi/linux/bpf.h | 9 + tools/lib/bpf/libbpf.map | 2 ++ 2 files changed, 11 insertions(+) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi

[PATCH bpf-next 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-24 Thread Brian Vazquez
, meaning that the returned buf might or might not be consistent. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- include/uapi/linux/bpf.h | 9 +++ kernel/bpf/syscall.c | 117 +++ 2 files changed, 126 insertions(+) diff --git a/include/uapi

[PATCH bpf-next 5/6] selftests/bpf: test BPF_MAP_DUMP command on a bpf hashmap

2019-07-24 Thread Brian Vazquez
This tests exercise the new command on a bpf hashmap and make sure it works as expected. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 83 - 1 file changed, 81 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf

[PATCH bpf-next 6/6] selftests/bpf: add test to measure performance of BPF_MAP_DUMP

2019-07-24 Thread Brian Vazquez
This tests compares the amount of time that takes to read an entire table of 100K elements on a bpf hashmap using both BPF_MAP_DUMP and BPF_MAP_GET_NEXT_KEY + BPF_MAP_LOOKUP_ELEM. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 65 + 1 file

[PATCH bpf-next 4/6] libbpf: support BPF_MAP_DUMP command

2019-07-24 Thread Brian Vazquez
Make libbpf aware of new BPF_MAP_DUMP command and add bpf_map_dump and bpf_map_dump_flags to use them from the library. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/lib/bpf/bpf.c | 28 tools/lib/bpf/bpf.h | 4 2 files changed, 32

[PATCH bpf-next 1/6] bpf: add bpf_map_value_size and bp_map_copy_value helper functions

2019-07-24 Thread Brian Vazquez
Move reusable code from map_lookup_elem to helper functions to avoid code duplication in kernel/bpf/syscall.c Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- kernel/bpf/syscall.c | 134 +++ 1 file changed, 73 insertions(+), 61 deletions

[PATCH bpf-next 0/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-24 Thread Brian Vazquez
s v2: - use proper bpf-next tag Brian Vazquez (6): bpf: add bpf_map_value_size and bp_map_copy_value helper functions bpf: add BPF_MAP_DUMP command to dump more than one entry per call bpf: keep bpf.h in sync with tools/ libbpf: support BPF_MAP_DUMP command selftests/bpf: test BPF_MAP_

Re: [PATCH bpf-next RFC v3 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-09 Thread Brian Vazquez
> Maybe you can swap map_fd and flags? > This way, you won't have hole right after map_fd? Makes sense. > > + attr->flags = 0; > Why do you want attr->flags? This is to modify anonumous struct used by > BPF_MAP_*_ELEM commands. Nice catch! This was a mistake I forgot to delete that line.

[PATCH bpf-next RFC v3 3/6] bpf: keep bpf.h in sync with tools/

2019-07-03 Thread Brian Vazquez
Adds bpf_attr.dump structure to libbpf. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/include/uapi/linux/bpf.h | 9 + 1 file changed, 9 insertions(+) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index a396b516a2b2..db6785a03538

[PATCH bpf-next RFC v3 5/6] selftests/bpf: test BPF_MAP_DUMP command on a bpf hashmap

2019-07-03 Thread Brian Vazquez
This tests exercise the new command on a bpf hashmap and make sure it works as expected. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 82 - 1 file changed, 80 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf

[PATCH bpf-next RFC v3 6/6] selftests/bpf: add test to measure performance of BPF_MAP_DUMP

2019-07-03 Thread Brian Vazquez
This tests compares the amount of time that takes to read an entire table of 100K elements on a bpf hashmap using both BPF_MAP_DUMP and BPF_MAP_GET_NEXT_KEY + BPF_MAP_LOOKUP_ELEM. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 65 + 1 file

[PATCH bpf-next RFC v3 0/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-03 Thread Brian Vazquez
y: 114427589 improvement 87.476941 Changelog: v3: - add explanation of the API in the commit message - fix masked errors and return them to user - copy last_key from return buf into prev_key if it was provided - run test with kpti and retpoline mitigations v2: - use proper bpf-next tag Brian Vazque

[PATCH bpf-next RFC v3 2/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call

2019-07-03 Thread Brian Vazquez
that the buf returned might or might not be consistent. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- include/uapi/linux/bpf.h | 9 +++ kernel/bpf/syscall.c | 118 +++ 2 files changed, 127 insertions(+) diff --git a/include/uapi/linux

[PATCH bpf-next RFC v3 1/6] bpf: add bpf_map_value_size and bp_map_copy_value helper functions

2019-07-03 Thread Brian Vazquez
Move reusable code from map_lookup_elem to helper functions to avoid code duplication in kernel/bpf/syscall.c Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- kernel/bpf/syscall.c | 134 +++ 1 file changed, 73 insertions(+), 61 deletions

[PATCH bpf-next RFC v3 4/6] libbpf: support BPF_MAP_DUMP command

2019-07-03 Thread Brian Vazquez
Make libbpf aware of new BPF_MAP_DUMP command and add bpf_map_dump and bpf_map_dump_flags to use them from the library. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/lib/bpf/bpf.c | 28 tools/lib/bpf/bpf.h | 4 tools/lib

Re: [RFC PATCH bpf-next v2 0/6] bpf: add BPF_MAP_DUMP command to

2019-06-28 Thread Brian Vazquez
> was it with kpti and retpoline mitigations? No, it wasn't. Will get back with new numbers.

Re: [RFC PATCH bpf-next v2 2/6] bpf: add BPF_MAP_DUMP command to access more than one entry per call

2019-06-28 Thread Brian Vazquez
> Please explain the api behavior and corner cases in the commit log > or in code comments. Ack, will prepare a new version adding those. > Would it make sense to return last key back into prev_key, > so that next map_dump command doesn't need to copy it from the > buffer? Actually that's a

[RFC PATCH bpf-next v2 5/6] selftests/bpf: test BPF_MAP_DUMP command on a bpf hashmap

2019-06-27 Thread Brian Vazquez
This tests exercise the new command on a bpf hashmap and make sure it works as expected. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 70 - 1 file changed, 68 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf

[RFC PATCH bpf-next v2 0/6] bpf: add BPF_MAP_DUMP command to

2019-06-27 Thread Brian Vazquez
ry: 89080077 improvement 86.670461% Changelog: v2: - use proper bpf-next tag Brian Vazquez (6): bpf: add bpf_map_value_size and bp_map_copy_value helper functions bpf: add BPF_MAP_DUMP command to access more than one entry per call bpf: keep bpf.h in sync with tools/ libbpf: support BPF_MAP_

[RFC PATCH bpf-next v2 3/6] bpf: keep bpf.h in sync with tools/

2019-06-27 Thread Brian Vazquez
Adds bpf_attr.dump structure to libbpf. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/include/uapi/linux/bpf.h | 9 + 1 file changed, 9 insertions(+) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index b077507efa3f3

[RFC PATCH bpf-next v2 2/6] bpf: add BPF_MAP_DUMP command to access more than one entry per call

2019-06-27 Thread Brian Vazquez
not be consistent. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- include/uapi/linux/bpf.h | 9 kernel/bpf/syscall.c | 108 +++ 2 files changed, 117 insertions(+) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index

[RFC PATCH bpf-next v2 6/6] selftests/bpf: add test to measure performance of BPF_MAP_DUMP

2019-06-27 Thread Brian Vazquez
This tests compares the amount of time that takes to read an entire table of 100K elements on a bpf hashmap using both BPF_MAP_DUMP and BPF_MAP_GET_NEXT_KEY + BPF_MAP_LOOKUP_ELEM. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 71 + 1 file

[RFC PATCH bpf-next v2 4/6] libbpf: support BPF_MAP_DUMP command

2019-06-27 Thread Brian Vazquez
Make libbpf aware of new BPF_MAP_DUMP command and add bpf_map_dump and bpf_map_dump_flags to use them from the library. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/lib/bpf/bpf.c | 28 tools/lib/bpf/bpf.h | 4 tools/lib

[RFC PATCH bpf-next v2 1/6] bpf: add bpf_map_value_size and bp_map_copy_value helper functions

2019-06-27 Thread Brian Vazquez
Move reusable code from map_lookup_elem to helper functions to avoid code duplication in kernel/bpf/syscall.c Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- kernel/bpf/syscall.c | 134 +++ 1 file changed, 73 insertions(+), 61 deletions

Re: [RFC PATCH 2/6] bpf: add BPF_MAP_DUMP command to access more than one entry per call

2019-06-24 Thread Brian Vazquez
On Mon, Jun 24, 2019 at 3:46 PM Jakub Kicinski wrote: > > On Fri, 21 Jun 2019 16:16:46 -0700, Brian Vazquez wrote: > > @@ -385,6 +386,14 @@ union bpf_attr { > > __u64 flags; > > }; > > > > + struct { /*

[RFC PATCH 2/6] bpf: add BPF_MAP_DUMP command to access more than one entry per call

2019-06-21 Thread Brian Vazquez
not be consistent. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- include/uapi/linux/bpf.h | 9 kernel/bpf/syscall.c | 108 +++ 2 files changed, 117 insertions(+) diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index

[RFC PATCH 3/6] bpf: keep bpf.h in sync with tools/

2019-06-21 Thread Brian Vazquez
Adds bpf_attr.dump structure to libbpf. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/include/uapi/linux/bpf.h | 9 + 1 file changed, 9 insertions(+) diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h index b077507efa3f3

[RFC PATCH 6/6] selftests/bpf: add test to measure performance of BPF_MAP_DUMP

2019-06-21 Thread Brian Vazquez
This tests compares the amount of time that takes to read an entire table of 100K elements on a bpf hashmap using both BPF_MAP_DUMP and BPF_MAP_GET_NEXT_KEY + BPF_MAP_LOOKUP_ELEM. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 71 + 1 file

[RFC PATCH 1/6] bpf: add bpf_map_value_size and bp_map_copy_value helper functions

2019-06-21 Thread Brian Vazquez
Move reusable code from map_lookup_elem to helper functions to avoid code duplication in kernel/bpf/syscall.c Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- kernel/bpf/syscall.c | 134 +++ 1 file changed, 73 insertions(+), 61 deletions

[RFC PATCH 5/6] selftests/bpf: test BPF_MAP_DUMP command on a bpf hashmap

2019-06-21 Thread Brian Vazquez
This tests exercise the new command on a bpf hashmap and make sure it works as expected. Signed-off-by: Brian Vazquez --- tools/testing/selftests/bpf/test_maps.c | 70 - 1 file changed, 68 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/bpf

[RFC PATCH 4/6] libbpf: support BPF_MAP_DUMP command

2019-06-21 Thread Brian Vazquez
Make libbpf aware of new BPF_MAP_DUMP command and add bpf_map_dump and bpf_map_dump_flags to use them from the library. Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez --- tools/lib/bpf/bpf.c | 28 tools/lib/bpf/bpf.h | 4 tools/lib

[RFC PATCH 0/6] bpf: add BPF_MAP_DUMP command to access more

2019-06-21 Thread Brian Vazquez
ry: 89080077 improvement 86.670461% Suggested-by: Stanislav Fomichev Signed-off-by: Brian Vazquez Brian Vazquez (6): bpf: add bpf_map_value_size and bp_map_copy_value helper functions bpf: add BPF_MAP_DUMP command to access more than one entry per call bpf: keep bpf.h in sync with tools/ lib

[PATCH] bpf: do not start from first bucket if elem is not found on a htab

2019-03-31 Thread Brian Vazquez
From: Brian Vazquez When you want to traverse an entire map using BPF_MAP_GET_NEXT_KEY and key provided is not present due to a deletion you will start iterating the map from the beginning without noticing it. This patch changes the starting bucket in those situations to the bucket where key