From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [PATCH bpf-next 2/2] bpftool: support loading flow dissector
Date: Wed, 7 Nov 2018 15:30:28 -0800
Message-ID: <20181107153028.43506cc5@cakuba.netronome.com>
References: <20181107193552.77894-1-sdf@google.com>
        <20181107193552.77894-3-sdf@google.com>
        <484ea7f5-0d4c-b828-c5fe-1fd4d9bf847d@netronome.com>
        <20181107123231.6d2f4782@cakuba.netronome.com>
        <6628387d-cf89-573f-7b9c-2d49ef19634e@netronome.com>
        <20181107221506.ha4c7wr4p2zswgjd@mini-arch>
        <20181107145122.170daba2@cakuba.netronome.com>
        <20181107231207.v425etmqm4v6rito@mini-arch>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Quentin Monnet <quentin.monnet@netronome.com>,
        Stanislav Fomichev <sdf@google.com>, netdev@vger.kernel.org,
        linux-kselftest@vger.kernel.org, ast@kernel.org,
        daniel@iogearbox.net, shuah@kernel.org, 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: Stanislav Fomichev <sdf@fomichev.me>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf1-f179.google.com ([209.85.210.179]:34637 "EHLO
        mail-pf1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726982AbeKHJDN (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 8 Nov 2018 04:03:13 -0500
Received: by mail-pf1-f179.google.com with SMTP id y18-v6so5998339pfn.1
        for <netdev@vger.kernel.org>; Wed, 07 Nov 2018 15:30:33 -0800 (PST)
In-Reply-To: <20181107231207.v425etmqm4v6rito@mini-arch>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, 7 Nov 2018 15:12:07 -0800, Stanislav Fomichev wrote:
> > > I agree, constructing the jmp_table is a bit fragile with all the
> > > dependencies on the order of the progs. I'll drop that and will send a
> > > v2 that pins all the programs from the obj file instead and offloads
> > > jmp_table construction to the user. So the supposed use case would be
> > > something like the following:
> > > 
> > > bpftool prog load bpf_flow.o /sys/fs/bpf/flow type flow_dissector  
> > 
> > Okay.  One more thing - how do we differentiate between mass pin and the
> > existing pin first behaviour?  Should we perhaps add a loadall command
> > or some flag?  
> In v2 I did by program type:
> * flow_dissector -> pin all
> * not flow_dissector -> pin first?
> 
> But we can have loadall or something like:
> load OBJ [pinfirst|pinall] FILE|DIR [type TYPE]
> 
> If we want to add user control, I'd go with loadall command,
> adding more optional flags in between is a mess..

I think user control would be good.  Agreed on loadall being better.