From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Stringer Subject: Re: [RFC PATCH bpf-next v2 0/4] Implement bpf queue/stack maps Date: Thu, 6 Sep 2018 23:27:07 -0700 Message-ID: References: <153575074884.30050.17670029209466860207.stgit@kernel> <20180907001317.fj7f6fg6ihljompp@ast-mbp.dhcp.thefacebook.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: mauricio.vasquez@polito.it, ast@kernel.org, daniel@iogearbox.net, netdev , Joe Stringer To: Alexei Starovoitov Return-path: Received: from mail-qt0-f170.google.com ([209.85.216.170]:43007 "EHLO mail-qt0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725831AbeIGLOl (ORCPT ); Fri, 7 Sep 2018 07:14:41 -0400 Received: by mail-qt0-f170.google.com with SMTP id z8-v6so15158377qto.9 for ; Thu, 06 Sep 2018 23:35:16 -0700 (PDT) In-Reply-To: <20180907001317.fj7f6fg6ihljompp@ast-mbp.dhcp.thefacebook.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 6 Sep 2018 at 17:13, Alexei Starovoitov 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