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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 01DB1C433C1 for ; Sun, 28 Mar 2021 04:33:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A9F036186A for ; Sun, 28 Mar 2021 04:33:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229563AbhC1EdW (ORCPT ); Sun, 28 Mar 2021 00:33:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229531AbhC1EdK (ORCPT ); Sun, 28 Mar 2021 00:33:10 -0400 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30656C061762; Sat, 27 Mar 2021 21:33:10 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id l15so10257324ybm.0; Sat, 27 Mar 2021 21:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CJibKbE2pHTeyp3O5gbay5BrG2Hry6PfPEoIAMQ+LSk=; b=ilPqnOEh9fQBeGtp0rwT2gyJ4dNWjAulC8oZ0D/S5B2eWMUYSJDsyGYZqlVHSnSCiS 1NNlIlTIt4yX7TOVrih/LdAnlhAzW14CMvh1Gux1Ar0diImXDqRYinu2QqDlyeU6cRlR Ze7W/H0V8FrM5T96ZIFQrLIxzgn3n9ePfN+iDi3/AyqmFTW1uZR/vtFr7vFAGNPVa6sF KONaM+2RO5WNqUNBlYgdQEzb3vSZkVSrtoQyFtF1vBL9k+9JGGR4Y+Bubf4doPK9VSOR 430uP9lXv7LiQR20e1pSsjGB+HQ/XrpmjehJLOn1PQ1Bn0LKZt0ITxBVYpM+9G2QEmn3 2nwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CJibKbE2pHTeyp3O5gbay5BrG2Hry6PfPEoIAMQ+LSk=; b=TmtRj3RYgC9hJLk4cI6ARb/bOQKRt6PFbtTGGoZ9w5LUJH8jnmZ14cGF7RNhwjFaBg CQs6wIHFMNBimuYpbT014DvYRjPsQeOF6eWC7JopXEe94OaPOwsN+mAR/zQPAA4p6/NW giAB4MVNx07dT/rGzBR/ql4DH2qE+j/jhmd0156/fNtMRhvYFwIwg0FLDWsXK1YuaLyF lKPB3QTqxZPRxOpN3hpJcWSDU12KkYkghxJVpbGb52WJCiwYxMDcME3CxlYEdmaY0N5E dqjdCGRHq3ghkn/9QOPV9cVCirKD8eaTkQabZ0urrcliyYOn5E/RsIkcie5gb5jJN98w Uinw== X-Gm-Message-State: AOAM531Rfyg8n5WzK8lHhgFSWdJLq2sl3RVyqjBlcZR5EHP6ZBG+tNPy QOaQp5qoNjqG3WUUW7AgxacZjWgM7WtWs6EIGso= X-Google-Smtp-Source: ABdhPJw+4nuWmp0dJnLLJo8TB3bkZkAg2joGu9L9FqfjWQrWzKjqP3IQ6U9kxxeMpUTCn4ISJc9ccw66DnyOzzlBkLE= X-Received: by 2002:a25:7d07:: with SMTP id y7mr29811546ybc.425.1616905989011; Sat, 27 Mar 2021 21:33:09 -0700 (PDT) MIME-Version: 1.0 References: <20210325120020.236504-1-memxor@gmail.com> <20210325120020.236504-6-memxor@gmail.com> <20210327021534.pjfjctcdczj7facs@ast-mbp> In-Reply-To: <20210327021534.pjfjctcdczj7facs@ast-mbp> From: Andrii Nakryiko Date: Sat, 27 Mar 2021 21:32:58 -0700 Message-ID: Subject: Re: [PATCH bpf-next 5/5] libbpf: add selftests for TC-BPF API To: Alexei Starovoitov Cc: Kumar Kartikeya Dwivedi , bpf , Jesper Dangaard Brouer , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Shuah Khan , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , Peter Zijlstra , open list , Networking , "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, Mar 26, 2021 at 7:15 PM Alexei Starovoitov wrote: > > On Thu, Mar 25, 2021 at 05:30:03PM +0530, Kumar Kartikeya Dwivedi wrote: > > This adds some basic tests for the low level bpf_tc_* API and its > > bpf_program__attach_tc_* wrapper on top. > > *_block() apis from patch 3 and 4 are not covered by this selftest. > Why were they added ? And how were they tested? > > Pls trim your cc. bpf@vger and netdev@vger would have been enough. > > My main concern with this set is that it adds netlink apis to libbpf while > we already agreed to split xdp manipulation pieces out of libbpf. > It would be odd to add tc apis now only to split them later. We weren't going to split out basic attach APIs at all. So bpf_set_link_xdp_fd() and bpf_program__attach_xdp() would stay in libbpf. libxdp/libxsk would contain higher-level APIs which establish additional conventions, beyond the basic operation of attaching BPF program to XDP hook. E.g, all the chaining and how individual XDP "sub-programs" are ordered, processed, updated/replaced, etc. That's all based on one particular convention that libxdp would establish, so that part shouldn't live in libbpf. So in that sense, having TC attach APIs makes sense to complete libbpf's APIs. I think it's totally in libbpf's domain to provide APIs of the form "attach BPF program to BPF hook". > I think it's better to start with new library for tc/xdp and have > libbpf as a dependency on that new lib. > For example we can add it as subdir in tools/lib/bpf/. > > Similarly I think integerating static linking into libbpf was a mistake. > It should be a sub library as well. > > If we end up with core libbpf and ten sublibs for tc, xdp, af_xdp, linking, > whatever else the users would appreciate that we don't shove single libbpf > to them with a ton of features that they might never use. What's the concern exactly? The size of the library? Having 10 micro-libraries has its own set of downsides, I'm not convinced that's a better situation for end users. And would certainly cause more hassle for libbpf developers and packagers. And what did you include in "core libbpf"?