From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stanislav Fomichev Subject: Re: [PATCH bpf-next 3/3] bpftool: support loading flow dissector Date: Wed, 7 Nov 2018 15:34:48 -0800 Message-ID: <20181107233448.r7vcnxtdzfnzegas@mini-arch> References: <20181107224356.73080-1-sdf@google.com> <20181107224356.73080-4-sdf@google.com> <20181107150944.5d5480ba@cakuba.netronome.com> <20181107231333.n34ffy4dl6rtbs7e@mini-arch> <20181107152917.729ea83c@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stanislav Fomichev , netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, shuah@kernel.org, quentin.monnet@netronome.com, guro@fb.com, jiong.wang@netronome.com, bhole_prashant_q7@lab.ntt.co.jp, john.fastabend@gmail.com, jbenc@redhat.com, treeze.taeung@gmail.com, yhs@fb.com, osk@fb.com, sandipan@linux.vnet.ibm.com To: Jakub Kicinski Return-path: Received: from mail-pl1-f195.google.com ([209.85.214.195]:43570 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727277AbeKHJHb (ORCPT ); Thu, 8 Nov 2018 04:07:31 -0500 Received: by mail-pl1-f195.google.com with SMTP id g59-v6so8581122plb.10 for ; Wed, 07 Nov 2018 15:34:51 -0800 (PST) Content-Disposition: inline In-Reply-To: <20181107152917.729ea83c@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On 11/07, Jakub Kicinski wrote: > On Wed, 7 Nov 2018 15:13:33 -0800, Stanislav Fomichev wrote: > > On 11/07, Jakub Kicinski wrote: > > > On Wed, 7 Nov 2018 14:43:56 -0800, Stanislav Fomichev wrote: > > > > bpftool map update pinned /sys/fs/bpf/flow/jmp_table \ > > > > key 0 0 0 0 \ > > > > value pinned /sys/fs/bpf/flow/IP/0 > > > > > > Where is that /0 coming from ? Is that in source code? I don't see > > > libbpf adding it, maybe I'm missing something. > > libbpf adds that, that's a program instance: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/bpf/libbpf.c#n1744 > > Ugh, I was looking at bpf_object__pin() which uses names :( > > We never use this multi-instance thing, and I don't think bpftool ever > will, so IMHO it'd be good if we just re-did the pinning loop in > bpftool. I wonder whether I should just add special case to bpf_program__pin: don't create a subdir when instances.nr == 1 (and just create a file pin for single instance)? In that case I can continue to use libbpf and don't reinvent the wheel. Any objections?