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=-8.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 A2C4FECE58D for ; Sat, 5 Oct 2019 10:30:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 83BEC222BE for ; Sat, 5 Oct 2019 10:30:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727612AbfJEKa4 convert rfc822-to-8bit (ORCPT ); Sat, 5 Oct 2019 06:30:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39060 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727122AbfJEKa4 (ORCPT ); Sat, 5 Oct 2019 06:30:56 -0400 Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4A7D87BDA5 for ; Sat, 5 Oct 2019 10:30:55 +0000 (UTC) Received: by mail-lj1-f199.google.com with SMTP id e3so2352183ljj.16 for ; Sat, 05 Oct 2019 03:30:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=0BTW7nl+H/XRQtnoJO4rjId8yr0bcribLIhknb5mLqw=; b=fPLXoWuVKxgkcAqP/iUrMgPZRhbysOA4Y5A1Zhw/PFeCAtaRDYdr8YmUYAGla7aC+Q 4nlX77wRWo2KkeevWa76p8fcvuUnzLQCJcjgGTAJgQ9FXqYq3sNqSKn5CAawIfvRMnmC TLI5T7u1+EbfJ4OXfzu6nYB0xxu9KUUPiU7RVvHNwphzoayBNq/nrvvrpaXyDiYysk+/ iY6hdgc0wdjVmVfvgPhW68fN+oTtEy0pTm43f4tP/jxytVsfxB8fOV20il+WinlRSisk j9PBhEqQftt237M3WEFCA3Dg/FX36s7N3oHqxHvUnR4M87qDFYf4/ZmZOMGdQt5AVTYw drwg== X-Gm-Message-State: APjAAAX7/OziT7tECd0oHFKp4gxKdmyywD/8HXFBcukPGiPpMUIDApZi kogn4z5d1Oddb67ZV9xKRAXv3BqKF8W84zQtBhBl3wiTlgSWUXJXbtayjXAyvJnmUTaPwu0G3gE gTl3RvKqUT32/V6Bx X-Received: by 2002:a2e:9e8b:: with SMTP id f11mr8734648ljk.153.1570271453843; Sat, 05 Oct 2019 03:30:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJyujM1Er185peAYODficBxekswVKPLsM3E8O4Zeu2pJ+E3A2prNs/g4ezxCnjlv2sPcVXWg== X-Received: by 2002:a2e:9e8b:: with SMTP id f11mr8734625ljk.153.1570271453536; Sat, 05 Oct 2019 03:30:53 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk (borgediget.toke.dk. [85.204.121.218]) by smtp.gmail.com with ESMTPSA id a23sm1620173lfl.66.2019.10.05.03.30.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Oct 2019 03:30:52 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 0182218063D; Sat, 5 Oct 2019 12:30:51 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jakub Kicinski Cc: Daniel Borkmann , Alexei Starovoitov , Martin KaFai Lau , Song Liu , Yonghong Song , Marek Majkowski , Lorenz Bauer , Alan Maguire , Jesper Dangaard Brouer , David Miller , netdev@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH bpf-next v2 2/5] bpf: Add support for setting chain call sequence for programs In-Reply-To: <20191004161842.617b8bd8@cakuba.hsd1.ca.comcast.net> References: <157020976030.1824887.7191033447861395957.stgit@alrua-x1> <157020976257.1824887.7683650534515359703.stgit@alrua-x1> <20191004161842.617b8bd8@cakuba.hsd1.ca.comcast.net> X-Clacks-Overhead: GNU Terry Pratchett Date: Sat, 05 Oct 2019 12:30:51 +0200 Message-ID: <87a7afo55w.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Jakub Kicinski writes: > On Fri, 04 Oct 2019 19:22:42 +0200, Toke Høiland-Jørgensen wrote: >> From: Alan Maguire >> >> This adds support for setting and deleting bpf chain call programs through >> a couple of new commands in the bpf() syscall. The CHAIN_ADD and CHAIN_DEL >> commands take two eBPF program fds and a return code, and install the >> 'next' program to be chain called after the 'prev' program if that program >> returns 'retcode'. A retcode of -1 means "wildcard", so that the program >> will be executed regardless of the previous program's return code. >> >> >> The syscall command names are based on Alexei's prog_chain example[0], >> which Alan helpfully rebased on current bpf-next. However, the logic and >> program storage is obviously adapted to the execution logic in the previous >> commit. >> >> [0] https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=prog_chain&id=f54f45d00f91e083f6aec2abe35b6f0be52ae85b&context=15 >> >> Signed-off-by: Alan Maguire >> Signed-off-by: Toke Høiland-Jørgensen > > It'd be good to explain why not just allocate a full prog array (or > in fact get one from the user), instead of having a hidden one which > requires new command to interact with? Because I consider the reuse of the prog array to be an implementation detail that we may want to change later. Whereas if we expose it to userspace it becomes API. For instance, if we do end up wanting to have support directly in the JIT for this, we could make the next progs just a linked list that the JIT will walk and emit direct call instructions for each, instead of doing the index-lookup. -Toke