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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 93467C433B4 for ; Wed, 21 Apr 2021 23:14:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F7D861404 for ; Wed, 21 Apr 2021 23:14:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343687AbhDUXPU (ORCPT ); Wed, 21 Apr 2021 19:15:20 -0400 Received: from www62.your-server.de ([213.133.104.62]:46940 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234867AbhDUXPT (ORCPT ); Wed, 21 Apr 2021 19:15:19 -0400 Received: from sslproxy02.your-server.de ([78.47.166.47]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lZM3P-000Er3-Ka; Thu, 22 Apr 2021 01:14:43 +0200 Received: from [85.7.101.30] (helo=linux.home) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lZM3P-000JQ5-Ad; Thu, 22 Apr 2021 01:14:43 +0200 Subject: Re: [PATCH bpf-next v3 2/3] libbpf: add low level TC-BPF API To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Andrii Nakryiko , Kumar Kartikeya Dwivedi Cc: bpf , Alexei Starovoitov , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Networking References: <20210420193740.124285-1-memxor@gmail.com> <20210420193740.124285-3-memxor@gmail.com> <87tunzh11d.fsf@toke.dk> From: Daniel Borkmann Message-ID: Date: Thu, 22 Apr 2021 01:14:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <87tunzh11d.fsf@toke.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.4/26147/Wed Apr 21 13:06:05 2021) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 4/21/21 9:48 PM, Toke Høiland-Jørgensen wrote: > Andrii Nakryiko writes: >> On Tue, Apr 20, 2021 at 12:37 PM Kumar Kartikeya Dwivedi >> wrote: [...] >>> --- >>> tools/lib/bpf/libbpf.h | 44 ++++++ >>> tools/lib/bpf/libbpf.map | 3 + >>> tools/lib/bpf/netlink.c | 319 ++++++++++++++++++++++++++++++++++++++- >>> 3 files changed, 360 insertions(+), 6 deletions(-) >>> >>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h >>> index bec4e6a6e31d..b4ed6a41ea70 100644 >>> --- a/tools/lib/bpf/libbpf.h >>> +++ b/tools/lib/bpf/libbpf.h >>> @@ -16,6 +16,8 @@ >>> #include >>> #include // for size_t >>> #include >>> +#include >>> +#include >> >> apart from those unused macros below, are these needed in public API header? >> >>> #include "libbpf_common.h" >>> >>> @@ -775,6 +777,48 @@ LIBBPF_API int bpf_linker__add_file(struct bpf_linker *linker, const char *filen >>> LIBBPF_API int bpf_linker__finalize(struct bpf_linker *linker); >>> LIBBPF_API void bpf_linker__free(struct bpf_linker *linker); >>> >>> +/* Convenience macros for the clsact attach hooks */ >>> +#define BPF_TC_CLSACT_INGRESS TC_H_MAKE(TC_H_CLSACT, TC_H_MIN_INGRESS) >>> +#define BPF_TC_CLSACT_EGRESS TC_H_MAKE(TC_H_CLSACT, TC_H_MIN_EGRESS) >> >> these seem to be used only internally, why exposing them in public >> API? > > No they're "aliases" for when you want to attach the filter directly to > the interface (and thus install the clsact qdisc as the root). You can > also use the filter with an existing qdisc (most commonly HTB), in which > case you need to specify the qdisc handle as the root. We have a few > examples of this use case: > > https://github.com/xdp-project/bpf-examples/tree/master/traffic-pacing-edt > and > https://github.com/xdp-project/xdp-cpumap-tc I'm a bit puzzled, could you elaborate on your use case on why you wouldn't use the tc egress hook for those especially given it's guaranteed to run outside of root qdisc lock? Some pointers as well: - http://vger.kernel.org/lpc-bpf2018.html#session-1 - https://netdevconf.info/0x14/session.html?talk-replacing-HTB-with-EDT-and-BPF - https://cilium.io/blog/2020/11/10/cilium-19#bwmanager Thanks, Daniel