linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Daniel Colascione <dancol@google.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Joel Fernandes <joelaf@google.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Tim Murray <timmurray@google.com>,
	netdev <netdev@vger.kernel.org>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Lorenzo Colitti <lorenzo@google.com>,
	Chenbo Feng <fengc@google.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Alexei Starovoitov <ast@fb.com>
Subject: Re: [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command
Date: Mon, 30 Jul 2018 18:14:50 -0700	[thread overview]
Message-ID: <20180730181450.4e0e1df8@cakuba.netronome.com> (raw)
In-Reply-To: <CAKOZuev_fRPjH6PWRnDpWo0OjOo2EF+at_Uw4JXs25mwKoWF1A@mail.gmail.com>

On Mon, 30 Jul 2018 17:50:15 -0700, Daniel Colascione wrote:
> > Tangentially it would be really useful for us to have a "the map has
> > actually been freed" notification/barrier.  We have complaints of users
> > creating huge maps and then trying to free and recreate them quickly,
> > and the creation part failing with -ENOMEM, because the free from a
> > workqueue didn't run, yet :(  It'd probably require a different API to
> > solve than what's discussed here, but since we're talking about syncing
> > things I thought I'd put it out there...  
> 
> Yeah. What you're talking about is what I meant upthread when I
> briefly mentioned a "refcount draining approach" --- you'd block until
> all references except your own to a map disappeared.

I don't think so.  The ref count goes to 0, work gets scheduled to call
free, work runs, free gets called, device memory gets freed.  Now the
memory can be reused.  As long as there are any refs we can't free
memory, unless we want to make the semantics really ugly.

But as I said, only superficially related to this patch.  Perhaps
solution will naturally fall out of an API to query the device
capabilities and resources, if we ever get there.

  reply	other threads:[~2018-07-31  1:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKOZuesQ6GdNTGDFsNi4o8LYzxLBtYZ=Cz4=aZbqqCNia+QFnQ@mail.gmail.com>
2018-07-29 20:58 ` [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command Daniel Colascione
2018-07-30 10:04   ` Daniel Borkmann
2018-07-30 10:25     ` Daniel Colascione
2018-07-31  0:26       ` Jakub Kicinski
2018-07-31  0:33         ` Daniel Colascione
2018-07-31  0:45           ` Jakub Kicinski
2018-07-31  0:50             ` Daniel Colascione
2018-07-31  1:14               ` Jakub Kicinski [this message]
2018-07-31  8:34           ` Daniel Borkmann
2018-07-31  9:36             ` Daniel Colascione
2018-08-10 22:52               ` Alexei Starovoitov
2018-08-14 20:37                 ` Daniel Colascione
2018-08-16  4:01                   ` Alexei Starovoitov
2018-10-12 10:54                     ` [PATCH v4] Wait for running BPF programs when updating map-in-map Daniel Colascione
2018-10-12 20:54                       ` Joel Fernandes
2018-10-13  2:31                       ` Alexei Starovoitov
2018-10-16 17:39                         ` Joel Fernandes
2018-10-18 15:46                           ` Alexei Starovoitov
2018-10-18 23:36                             ` Joel Fernandes
2018-11-10  2:01                               ` Chenbo Feng
2018-11-10 15:22                                 ` Greg KH
2018-11-10 18:58                                   ` Chenbo Feng
     [not found]   ` <CAKOZues6SE_c=ix7ap6QaJHqd1TmYpWWMJiu3=TtuqgKuqOUCA@mail.gmail.com>
2018-08-10 22:29     ` [PATCH v3] Add BPF_SYNCHRONIZE_MAP_TO_MAP_REFERENCES bpf(2) command 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=20180730181450.4e0e1df8@cakuba.netronome.com \
    --to=jakub.kicinski@netronome.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@fb.com \
    --cc=dancol@google.com \
    --cc=daniel@iogearbox.net \
    --cc=fengc@google.com \
    --cc=joelaf@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo@google.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=netdev@vger.kernel.org \
    --cc=timmurray@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).