From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Subject: Re: [PATCH v3 bpf-next 4/4] bpftool: support loading flow dissector
Date: Thu, 8 Nov 2018 13:52:47 -0800
Message-ID: <20181108135247.33cfabdf@cakuba.hsd1.ca.comcast.net>
References: <20181108053957.205681-1-sdf@google.com>
        <20181108053957.205681-5-sdf@google.com>
        <8c35340e-3ed7-70cd-3123-7cd0fb8824a7@netronome.com>
        <20181108114544.1ac0cd44@cakuba.hsd1.ca.comcast.net>
        <20181108212539.esqjw4k5hz2pxowu@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-yw1-f66.google.com ([209.85.161.66]:43146 "EHLO
        mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727266AbeKIHaT (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 9 Nov 2018 02:30:19 -0500
Received: by mail-yw1-f66.google.com with SMTP id j75-v6so8647232ywj.10
        for <netdev@vger.kernel.org>; Thu, 08 Nov 2018 13:52:53 -0800 (PST)
In-Reply-To: <20181108212539.esqjw4k5hz2pxowu@mini-arch>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Thu, 8 Nov 2018 13:25:39 -0800, Stanislav Fomichev wrote:
> > > > +			goto err_close_obj;
> > > > +		}
> > > > +
> > > >   		const char *sec_name = bpf_program__title(prog, false);
> > > >   
> > > >   		err = libbpf_prog_type_by_name(sec_name, &attr.prog_type,
> > > > @@ -936,8 +958,13 @@ static int do_load(int argc, char **argv)
> > > >   			goto err_close_obj;
> > > >   		}
> > > >   	}
> > > > -	bpf_program__set_type(prog, attr.prog_type);
> > > > -	bpf_program__set_expected_attach_type(prog, expected_attach_type);
> > > > +
> > > > +	bpf_object__for_each_program(pos, obj) {
> > > > +		bpf_program__set_ifindex(pos, ifindex);
> > > > +		bpf_program__set_type(pos, attr.prog_type);
> > > > +		bpf_program__set_expected_attach_type(pos,
> > > > +						      expected_attach_type);
> > > > +	}    
> > > 
> > > I still believe you can have programs of different types here, and be 
> > > able to load them. I tried it and managed to have it working fine. If no 
> > > type is provided from command line we can retrieve types for each 
> > > program from its section name. If a type is provided on the command 
> > > line, we can do the same, but I am not sure we should do it, or impose 
> > > that type for all programs instead.  
> > 
> > attr->prog_type is one per object, though.  How do we set that one?  
> Isn't it used only in __bpf_object__open_xattr to require/not-require kernel
> version in the bpf prog?
> 
> It will probably work quite nicely for both of our options:
> 
> * type not specified: prog_type = BPF_PROG_TYPE_UNSPEC, need kernel
>   version (over cautious?)
> * type specified (and applied to all progs): using bpf_prog_type__needs_kver
>   to require/not requqire kernel version

Right, but they you can't infer it from the program name, since there's
multiple.