All of lore.kernel.org
 help / color / mirror / Atom feed
From: dev@der-flo.net
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Hou Tao <houtao@huaweicloud.com>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eddy Z <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Anton Protopopov <aspsk@isovalent.com>,
	Kees Cook <kees@kernel.org>,
	Abhishek Chauhan <quic_abchauha@quicinc.com>,
	Martin Kelly <martin.kelly@crowdstrike.com>,
	Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
	yikai.lin@vivo.com
Subject: Re: [bpf-next 0/2] bpf: Add flag for batch operation
Date: Tue, 12 Nov 2024 20:13:33 +0100	[thread overview]
Message-ID: <ZzOo3ZTefm8Pf6st@der-flo.net> (raw)
In-Reply-To: <CAADnVQKKaNkmyCX5EwL+k0YZXFFrT4v+QtwDX6_7d7oJXjp=UQ@mail.gmail.com>

On Mon, Nov 11, 2024 at 07:01:26PM -0800, Alexei Starovoitov wrote:
> On Mon, Nov 11, 2024 at 6:15 AM Hou Tao <houtao@huaweicloud.com> wrote:
> >
> >
> >
> > On 11/10/2024 7:29 PM, Florian Lehner wrote:
> > > Introduce a new flag for batch operations that allows the deletion process
> > > to continue even if certain keys are missing. This simplifies map flushing
> > > by eliminating the requirement to maintain a separate list of keys and
> > > makes sure maps can be flushed with a single batch delete operation.
> >
> > Is it expensive to close and recreate a new map instead ? If it is
> > expensive, does it make more sense to add a new command to delete all
> > elements in the map ? Because reusing the deletion logic will make each
> > deletion involve an unnecessary lookup operation.
> 
> +1 to above questions.

There is an eBPF map, that a variable number of eBPF programs use, to access
common states for a variable number of connections. On predefined events, a set
of keys is deleted from this map. This set can either be all keys or just a
subset of all keys - but it is not guaranteed that this set of keys still exists
in this eBPF map.
The current work around is to use bpf_map_lookup_and_delete_batch(), as this
operation continues on missing keys and clears all requested keys from the eBPF
map. The noticeable downside of bpf_map_lookup_and_delete_batch() is the memory
requirement that comes with the lookup and allocation for the values.

> > [..] If it is
> > expensive, does it make more sense to add a new command to delete all
> > elements in the map ?

It felt like bpf_map_delete_batch() was introduced for this use case. So adding
a new command was not considered.

> 
> In addition:
> 
> What is the use case ?
> Are you trying to erase all elements from the map ?
> 
> If so you bpf_for_each_map_elem() and delete elems while iterating.

bpf_for_each_map_elem() could be an option if the map should be flushed
completley, but in most cases only a subset of keys should be removed from the
map.

> 
> This extra flag looks too specific.

Sure, the proposed flag is focused on the delete operation. What could be the
requirement to make it less specific?

> 
> pw-bot: cr

  reply	other threads:[~2024-11-12 19:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-10 11:29 [bpf-next 0/2] bpf: Add flag for batch operation Florian Lehner
2024-11-10 11:29 ` [bpf-next 1/2] bpf: Add flag to continue " Florian Lehner
2024-11-10 11:29 ` [bpf-next 2/2] selftests/bpf: Add a test for batch operation flag Florian Lehner
2024-11-11 14:15 ` [bpf-next 0/2] bpf: Add flag for batch operation Hou Tao
2024-11-12  3:01   ` Alexei Starovoitov
2024-11-12 19:13     ` dev [this message]
2024-11-12 19:47       ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZzOo3ZTefm8Pf6st@der-flo.net \
    --to=dev@der-flo.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=aspsk@isovalent.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=houtao@huaweicloud.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kees@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=martin.kelly@crowdstrike.com \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=quic_abchauha@quicinc.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yikai.lin@vivo.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.