Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp262199pxf; Wed, 31 Mar 2021 02:47:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOtj9F1Hkyp2XicefCWScv9+o8h/ZmgbObiNctDUNMVBHoOwXusr+rf+luROD0rvogKrVv X-Received: by 2002:a50:fb10:: with SMTP id d16mr2612874edq.73.1617184051656; Wed, 31 Mar 2021 02:47:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617184051; cv=none; d=google.com; s=arc-20160816; b=EhTODshnRV9S/RveUP64/vx2W2dL9ff1+blTa1kiqjt5DIQbpxdSRCPm/AmtH6wNb4 y+yLK7UOFwac514SU13D2UY/Cdo9FuMk3GxfBUiaFsUlbsIVTU1MRHVmSircTpNPj/JB AQXV7hbpfwMZndWYN+bCgyxD08xjiWpGnEc6MYrWanjRIPAYsgPh/6/F+w5lXSpKIP4/ g6IZY+vGIcslKW8+czwRutkYwjdQ+JDqlrMsOLM57ogk6Mao663P6r43PCG/C619YdF9 V/qDIuBcg8EggTs5rRTRjDRPqoZevSmxTKalv/iPr5xV4F262SJzHjUgj3ieQcz4Q40m Q5pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=1NaGZElvCoRWL/RIn8TQFlNEAVOA5Cl0KeXtUDOHtaw=; b=ibx10mqaSzReb1lYC5EEZEkOfLWj9pgmnEgvUljQy1eW4v+xlje18oH2liqFMCbmU9 WxqujCJpWxnwlNztJsDy/rnrDCMaKH/dAbXuPkN7z9qpsv9UqqHcAgHAgCXatJN1Tzsk q8U5XtCMtaDDfPAYnJuZ+WCyfBfM/M/XASy069INJdUYlq+2EpR7IC3kPLnUNaGwNMla 93j8h5+P0INWNiRci9gG2JsSyOmG7Oy75CImDUBPRlu8Wyl/+InNP+nT0HcHVP44VTkU WnJZrCBnOO+5xkgCuuhzBGj+u4GO6GBHBbMq5yeR8wo0z/9Tvg/V1SebN3pVVcaTzzr1 jMzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yxl51jwe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s23si1229843eja.266.2021.03.31.02.47.08; Wed, 31 Mar 2021 02:47:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Yxl51jwe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234864AbhCaJoO (ORCPT + 99 others); Wed, 31 Mar 2021 05:44:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234614AbhCaJoE (ORCPT ); Wed, 31 Mar 2021 05:44:04 -0400 Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5691AC061574; Wed, 31 Mar 2021 02:44:04 -0700 (PDT) Received: by mail-pj1-x1041.google.com with SMTP id kr3-20020a17090b4903b02900c096fc01deso927416pjb.4; Wed, 31 Mar 2021 02:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=1NaGZElvCoRWL/RIn8TQFlNEAVOA5Cl0KeXtUDOHtaw=; b=Yxl51jwe+G2xZh4UwJgg+DJZfGaCdDWxAcwbTRDVEUi4lTQUfrkjix++jmLmndiABA ZFaXdVp/22JqBjWgC+/24UIrS0LJkpsP4QWmGWZ8JrIxbVLcN+V16cBLl27PqxZIQ6ts EK69F7IHu5/07I2YM9BpsI2ZmVSINBG4KQKX7u9UYYM1LWiOZ99zplpm6ZSAfunsnwa/ 1RimpyU2S05Qca/3mWYJCOtMC2AR+bMcqH/Tje1IF7HiLRnBcUJyGU/dmP0thSURBuhm 4hSL3pvC3QkvNsc7BVhR7FNHvxm98a8cCq43F7+boR1ZMDUCc/J0FaF/rVfvjAsbSoSn c82Q== 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:references :mime-version:content-disposition:in-reply-to; bh=1NaGZElvCoRWL/RIn8TQFlNEAVOA5Cl0KeXtUDOHtaw=; b=LP8l/pu+YB9wmwQkdWVEMaXI4pU/7ouaYQr+H7w1J7T/LqURjh7f15uIYTgFMxptqD 882mqH35b+Gi7xWz78CPMRUSX4wxrA3CVQ3SpJkA/kdjx2asHZ+Fh2s0rSOS5HT/QfwX Eh///iK11j+N+71ITSD/gD8aDdzQVimxeor03j+XXOKxZs//J7lrTq2kZxl595krnbPe r0QZ/VI283ONXoPLgPzWWq6i76sIuURLnnVwwsXLoco9FSu2cMGvqQov3Qsj4ZPCokSc U4jZM1Mefo2zFHF8iWeIxzilfUiEZGxwV/o28XAKc3Ov9Bz9i2stsseAJUv/clw+Hz2i eH0g== X-Gm-Message-State: AOAM533y0mqJFp5xEPNbu/ACI3e7ksPklDFm9uZHkLpB2OzgfMebTKrZ Raii4De8JmEtGr2qkcAE0Map03FF2TMuMg== X-Received: by 2002:a17:902:ed84:b029:e7:1f2b:1eb4 with SMTP id e4-20020a170902ed84b02900e71f2b1eb4mr2460736plj.74.1617183843799; Wed, 31 Mar 2021 02:44:03 -0700 (PDT) Received: from localhost ([47.9.181.160]) by smtp.gmail.com with ESMTPSA id j26sm1708923pfn.47.2021.03.31.02.44.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Mar 2021 02:44:03 -0700 (PDT) Date: Wed, 31 Mar 2021 15:14:00 +0530 From: Kumar Kartikeya Dwivedi To: Daniel Borkmann Cc: Andrii Nakryiko , bpf , Jesper Dangaard Brouer , Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= , Alexei Starovoitov , 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" Subject: Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API Message-ID: <20210331094400.ldznoctli6fljz64@apollo> References: <20210325120020.236504-1-memxor@gmail.com> <20210325120020.236504-4-memxor@gmail.com> <20210328080648.oorx2no2j6zslejk@apollo> <48b99ccc-8ef6-4ba9-00f9-d7e71ae4fb5d@iogearbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48b99ccc-8ef6-4ba9-00f9-d7e71ae4fb5d@iogearbox.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 31, 2021 at 02:55:47AM IST, Daniel Borkmann wrote: > Do we even need the _block variant? I would rather prefer to take the chance > and make it as simple as possible, and only iff really needed extend with > other APIs, for example: The block variant can be dropped, I'll use the TC_BLOCK/TC_DEV alternative which sets parent_id/ifindex properly. > > bpf_tc_attach(prog_fd, ifindex, {INGRESS,EGRESS}); > > Internally, this will create the sch_clsact qdisc & cls_bpf filter instance > iff not present yet, and attach to a default prio 1 handle 1, and _always_ in > direct-action mode. This is /as simple as it gets/ and we don't need to bother > users with more complex tc/cls_bpf internals unless desired. For example, > extended APIs could add prio/parent so that multi-prog can be attached to a > single cls_bpf instance, but even that could be a second step, imho. > I am not opposed to clsact qdisc setup if INGRESS/EGRESS is supplied (not sure how others feel about it). We could make direct_action mode default, and similarly choose prio as 1 by default instead of letting the kernel do it. Then you can just pass in NULL for bpf_tc_cls_opts and be close to what you're proposing. For protocol we can choose ETH_P_ALL by default too if the user doesn't set it. With these modifications, the equivalent would look like bpf_tc_cls_attach(prog_fd, TC_DEV(ifindex, INGRESS), NULL, &id); So as long as the user doesn't care about other details, they can just pass opts as NULL. WDYT? > Thanks, > Daniel -- Kartikeya