From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF1A0C282C0 for ; Wed, 23 Jan 2019 13:42:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 993322184C for ; Wed, 23 Jan 2019 13:42:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="o7LW2/0v" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726337AbfAWNmM (ORCPT ); Wed, 23 Jan 2019 08:42:12 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:36878 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbfAWNmM (ORCPT ); Wed, 23 Jan 2019 08:42:12 -0500 Received: by mail-pl1-f195.google.com with SMTP id b5so1207802plr.4 for ; Wed, 23 Jan 2019 05:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7wToLBnKvh+mRHuaDQGkhl84mp+Sh/jmV8cH6Nk4cGs=; b=o7LW2/0vbRvgEfCe/fqxrI/9k5GRWXiQKBqy7GpW5IAuA3hzMxKsfB35RQq8LeL31v s7ENrhy/BxV9DdZKinHSei9eMt1Vtm0S/OO7gEjIcEYgqq4ZK9Af4laa5yoeHnFeYEoI 3Iod8IM0G2SZlPRzbUW3y/SeF+e/9aQCOK1XNNco821TreMzs2peF32x3/W6rFw+BxAv dHofJh9mNWrCTmKE4bp2owEHMA+5PV3dLY5rYs5zqefQHc547+Kg/3STZaLq5RDBfjFC vQEXW8isv7tGpYi+9tTSUW8wzPR3jTDtw5MhYEOFmQ/vDp+Z8aWBkeCxAS6/zp+U5+SS Rvzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7wToLBnKvh+mRHuaDQGkhl84mp+Sh/jmV8cH6Nk4cGs=; b=qTRC3gw74ZLf6v89hjQK9M1NOKdzPNdB3qO8LZVD8f0g9k2WiPl8sPFpImKwFPLLdT WdALItcRrzd6yJZeQbe7b6xKgpRN0trtpO2cWhjpWG618dtMfc9UWZdCcM8n9p8fgbzh CFv4wccBIJ0VOFzG4JWFZvAO95stSt71vogsL6KY/dyp3VpDQQQbL3CKEOkztUoCGIpD +i8e+WOtGuuBPt10rDYgGlgbMGz4PkXzFdHsYGGTtS80cV0qJgo9ULM0CLth6lNT3KcD ZHAdjTCS0uinpg97hLmMfCVjYtdOP8YrBWsftM9GjYuCDCUkbLLen/YhN87v944XE1Xf RCMw== X-Gm-Message-State: AJcUukeaJPzMvLahmuT6oB8Ha32dECyghxGbqx5dKiGzQ/HCyJnDLfoa Jy186VxuflxFmO00bTIwMPg= X-Google-Smtp-Source: ALg8bN7LlWtvD4lxiJTPZjToA0LikydVZhuSzBowbOs7poU+WAwkbj7/qKwCvxP9FSAg/vqblb8JBQ== X-Received: by 2002:a17:902:d697:: with SMTP id v23mr2222399ply.261.1548250931149; Wed, 23 Jan 2019 05:42:11 -0800 (PST) Received: from localhost ([192.55.54.42]) by smtp.gmail.com with ESMTPSA id 125sm27985316pfg.39.2019.01.23.05.42.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 23 Jan 2019 05:42:10 -0800 (PST) Date: Wed, 23 Jan 2019 14:41:59 +0100 From: Maciej Fijalkowski To: Daniel Borkmann Cc: ast@kernel.org, netdev@vger.kernel.org, jakub.kicinski@netronome.com, brouer@redhat.com Subject: Re: [PATCH bpf-next v2 2/8] libbpf: Add a helper for retrieving a prog via index Message-ID: <20190123144159.000051bd@gmail.com> In-Reply-To: <91d162e0-3d15-c1d8-1e80-8d0a4f561540@iogearbox.net> References: <20190121091041.14666-1-maciejromanfijalkowski@gmail.com> <20190121091041.14666-3-maciejromanfijalkowski@gmail.com> <91d162e0-3d15-c1d8-1e80-8d0a4f561540@iogearbox.net> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, 23 Jan 2019 11:41:11 +0100 Daniel Borkmann wrote: > On 01/21/2019 10:10 AM, Maciej Fijalkowski wrote: > > xdp_redirect_cpu has a 6 different XDP programs that can be attached to > > network interface. This sample has a option --prognum that allows user > > for specifying which particular program from a given set will be > > attached to network interface. > > In order to make it easier when converting the mentioned sample to > > libbpf usage, add a function to libbpf that will return program's fd for > > a given index. > > > > Note that there is already a bpf_object__find_prog_by_idx, which could > > be exported and might be used for that purpose, but it operates on the > > number of ELF section and here we need an index from a programs array > > within the bpf_object. > > Series in general looks good to me. Few minor comments, mainly in relation > to the need for libbpf extensions. > > Would it not be a better interface to the user to instead choose the prog > based on section name and then retrieve it via bpf_object__find_program_by_title() > instead of prognum (which feels less user friendly) at least? > I couldn't decide which one from: * adding a libbpf helper * changing the xdp_redirect_cpu behaviour would be more invasive when I was converting this sample to libbpf support. Your suggestion sounds good, but I'm wondering about the actual implementation. I suppose that we would choose the program via command line. Some program section names in this sample are a bit long and it might be irritating for user to type in for example "xdp_cpu_map5_lb_hash_ip_pairs", no? Or maybe we can live with this. In case of typo and program being not found it would be good to print out the section names to choose from in usage(). > > Signed-off-by: Maciej Fijalkowski > > Reviewed-by: Jakub Kicinski > > --- > > tools/lib/bpf/libbpf.c | 8 ++++++++ > > tools/lib/bpf/libbpf.h | 3 +++ > > tools/lib/bpf/libbpf.map | 1 + > > 3 files changed, 12 insertions(+) > > > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c > > index dc838bea403f..21c84d0f6128 100644 > > --- a/tools/lib/bpf/libbpf.c > > +++ b/tools/lib/bpf/libbpf.c > > @@ -935,6 +935,14 @@ static int bpf_object__elf_collect(struct bpf_object *obj, int flags) > > return err; > > } > > > > +int > > +bpf_object__get_prog_fd_by_num(struct bpf_object *obj, int idx) > > +{ > > + if (idx >= 0 && idx < obj->nr_programs) > > + return bpf_program__fd(&obj->programs[idx]); > > + return -ENOENT; > > +} > > + > > static struct bpf_program * > > bpf_object__find_prog_by_idx(struct bpf_object *obj, int idx) > > { > > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h > > index 7f10d36abdde..ca1b381cb3ad 100644 > > --- a/tools/lib/bpf/libbpf.h > > +++ b/tools/lib/bpf/libbpf.h > > @@ -95,6 +95,9 @@ LIBBPF_API int bpf_object__btf_fd(const struct bpf_object *obj); > > LIBBPF_API struct bpf_program * > > bpf_object__find_program_by_title(struct bpf_object *obj, const char *title); > > > > +LIBBPF_API int > > +bpf_object__get_prog_fd_by_num(struct bpf_object *obj, int idx); > > + > > LIBBPF_API struct bpf_object *bpf_object__next(struct bpf_object *prev); > > #define bpf_object__for_each_safe(pos, tmp) \ > > for ((pos) = bpf_object__next(NULL), \ > > diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map > > index 7c59e4f64082..871d2fc07150 100644 > > --- a/tools/lib/bpf/libbpf.map > > +++ b/tools/lib/bpf/libbpf.map > > @@ -127,4 +127,5 @@ LIBBPF_0.0.1 { > > LIBBPF_0.0.2 { > > global: > > bpf_object__find_map_fd_by_name; > > + bpf_object__get_prog_fd_by_num; > > } LIBBPF_0.0.1; > > >