On Mon, Feb 10, 2025 at 4:19 AM Jiri Olsa wrote:
>
> On Sun, Feb 09, 2025 at 11:22:35PM -0800, Yan Zhai wrote:
> > The generic_map_lookup_batch currently returns EINTR if it fails with
> > ENOENT and retries several times on bpf_map_copy_value. The next batch
> > would start from the same location
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 batc
patch 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
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
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
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
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
patch 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
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
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
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
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
06 4.3734106e-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:
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
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| 7
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 b/inc
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
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 a/include/net/dst
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 c
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 b/inc
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
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
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
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 100
'
make: *** [Makefile:1166: vmlinux] 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
'
make: *** [Makefile:1166: vmlinux] 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
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
> > clea
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
> > clea
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
.
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..41181cd489ea 10
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 lo
6 +0200, Sven Joachim 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-yueh
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
>^
>
>
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 min
/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 |
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
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 -0700
hwell
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 @@
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
s in 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/f
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
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
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
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
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
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
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 &
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
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 i
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/
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.
> >
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
> > -
> > > 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 wa
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
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
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
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
1 entry at the time, 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
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
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
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
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
ations
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_
> 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.
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
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
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
-entry: 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 V
e time, meaning 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
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
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
> was it with kpti and retpoline mitigations?
No, it wasn't. Will get back with new numbers.
> 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 good
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
y-entry: 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
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
ot 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
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
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
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
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 { /*
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
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
ot 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
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
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
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
y-entry: 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/
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 was
89 matches
Mail list logo
