All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Stringer <joe@wand.net.nz>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: mauricio.vasquez@polito.it, ast@kernel.org, daniel@iogearbox.net,
	netdev <netdev@vger.kernel.org>, Joe Stringer <joe@wand.net.nz>
Subject: Re: [RFC PATCH bpf-next v2 0/4] Implement bpf queue/stack maps
Date: Thu, 6 Sep 2018 23:27:07 -0700	[thread overview]
Message-ID: <CAOftzPjG3CT3ZP4e=5YUyUC_vTW5X_s=TUXSdrLEc-bP8hXoXg@mail.gmail.com> (raw)
In-Reply-To: <20180907001317.fj7f6fg6ihljompp@ast-mbp.dhcp.thefacebook.com>

On Thu, 6 Sep 2018 at 17:13, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> bpf_map_pop_elem() is trying to do lookup_and_delete and preserve
> validity of value without races.
> With pcpu_freelist I don't think there is a solution.
> We can have this queue/stack map without prealloc and use kmalloc/kfree
> back and forth. Performance will not be as great, but for your use case,
> I suspect, it will be good enough.
> The key issue with kmalloc/kfree is unbounded time of rcu callbacks.
> If somebody starts doing push/pop for every packet, the rcu subsystem
> will struggle and nothing we can do about it.
>
> The only way I could think of to resolve this problem is to reuse
> the logic that Joe is working on for socket lookups inside the program.
> Joe,
> how is that going? Could you repost the latest patches?

I can rebase & send them out. Was just wanting to get a little more testing in.

Cheers,
Joe

  reply	other threads:[~2018-09-07 11:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 21:25 [RFC PATCH bpf-next v2 0/4] Implement bpf queue/stack maps Mauricio Vasquez B
2018-08-31 21:25 ` [RFC PATCH bpf-next v2 1/4] bpf: add bpf queue and stack maps Mauricio Vasquez B
2018-08-31 21:26 ` [RFC PATCH bpf-next v2 2/4] bpf: restrict use of peek/push/pop Mauricio Vasquez B
2018-09-07  0:13 ` [RFC PATCH bpf-next v2 0/4] Implement bpf queue/stack maps Alexei Starovoitov
2018-09-07  6:27   ` Joe Stringer [this message]
2018-09-07 20:40   ` Mauricio Vasquez
2018-09-11  1:04 Alexei Starovoitov
2018-09-11 14:48 ` Mauricio Vasquez

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='CAOftzPjG3CT3ZP4e=5YUyUC_vTW5X_s=TUXSdrLEc-bP8hXoXg@mail.gmail.com' \
    --to=joe@wand.net.nz \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=mauricio.vasquez@polito.it \
    --cc=netdev@vger.kernel.org \
    /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.