lkml.org 
[lkml]   [2019]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Date
    SubjectRe: [RFC bpf-next 2/3] tools/bpf: test bpf_map_lookup_and_delete_batch()
    On Thu, Nov 7, 2019 at 1:23 PM Brian Vazquez <brianvv@google.com> wrote:
    >
    > From: Yonghong Song <yhs@fb.com>
    >
    > Added four libbpf API functions to support map batch operations:
    > . int bpf_map_delete_batch( ... )
    > . int bpf_map_lookup_batch( ... )
    > . int bpf_map_lookup_and_delete_batch( ... )
    > . int bpf_map_update_batch( ... )
    >
    > Tested bpf_map_lookup_and_delete_batch() and bpf_map_update_batch()
    > functionality.
    > $ ./test_maps
    > ...
    > test_map_lookup_and_delete_batch:PASS
    > ...
    >
    > Note that I clumped uapi header sync patch, libbpf patch
    > and tests patch together considering this is a RFC patch.
    > Will do proper formating once it is out of RFC stage.
    >
    > Signed-off-by: Yonghong Song <yhs@fb.com>
    > ---

    [...]

    >
    > + struct { /* struct used by BPF_MAP_*_BATCH commands */
    > + __u64 batch; /* input/output:
    > + * input: start batch,
    > + * 0 to start from beginning.
    > + * output: next start batch,
    > + * 0 to end batching.
    > + */
    > + __aligned_u64 keys;
    > + __aligned_u64 values;
    > + __u32 count; /* input/output:
    > + * input: # of elements keys/values.
    > + * output: # of filled elements.
    > + */
    > + __u32 map_fd;
    > + __u64 elem_flags;
    > + __u64 flags;
    > + } batch;
    > +

    Describe what elem_flags and flags are here?

    [...]

    > +LIBBPF_API int bpf_map_delete_batch(int fd, __u64 *batch, __u32 *count,
    > + __u64 elem_flags, __u64 flags);
    > +LIBBPF_API int bpf_map_lookup_batch(int fd, __u64 *batch, void *keys,
    > + void *values, __u32 *count,
    > + __u64 elem_flags, __u64 flags);
    > +LIBBPF_API int bpf_map_lookup_and_delete_batch(int fd, __u64 *batch,
    > + void *keys, void *values,
    > + __u32 *count, __u64 elem_flags,
    > + __u64 flags);
    > +LIBBPF_API int bpf_map_update_batch(int fd, void *keys, void *values,
    > + __u32 *count, __u64 elem_flags,
    > + __u64 flags);

    Should we start using the same approach as with bpf_object__open_file
    (see LIBBPF_OPTS), so that we can keep adding extra fields without
    breaking ABI? The gist is: use function arguments for mandatory fields
    (as of right now, at least), and put all the optional fields into a
    xxx_opts struct, which can be NULL. Please see
    bpf_object__open_{file,mem} for details.

    > +
    > LIBBPF_API int bpf_obj_pin(int fd, const char *pathname);
    > LIBBPF_API int bpf_obj_get(const char *pathname);
    > LIBBPF_API int bpf_prog_attach(int prog_fd, int attachable_fd,
    > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
    > index 86173cbb159d3..0529a770a04eb 100644
    > --- a/tools/lib/bpf/libbpf.map
    > +++ b/tools/lib/bpf/libbpf.map
    > @@ -189,6 +189,10 @@ LIBBPF_0.0.4 {
    > LIBBPF_0.0.5 {
    > global:
    > bpf_btf_get_next_id;
    > + bpf_map_delete_batch;
    > + bpf_map_lookup_and_delete_batch;
    > + bpf_map_lookup_batch;
    > + bpf_map_update_batch;
    > } LIBBPF_0.0.4;

    This should be in 0.0.6 section now.

    >

    [...]

    \
     
     \ /
      Last update: 2019-11-15 23:42    [W:4.224 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site