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=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 98014C433DF for ; Sat, 30 May 2020 07:20:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5EF632075A for ; Sat, 30 May 2020 07:20:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hJQE1SgH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728642AbgE3HUC (ORCPT ); Sat, 30 May 2020 03:20:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726843AbgE3HUC (ORCPT ); Sat, 30 May 2020 03:20:02 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23E01C03E969; Sat, 30 May 2020 00:20:02 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id g18so3869363qtu.13; Sat, 30 May 2020 00:20:02 -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=+GY3oCb8k4ZoxDmYR0zizW+h7H+4Er+voGLPiRHg8M8=; b=hJQE1SgHlmzaVnCtS1DWmA8sQMIcVIXy2N7dht8Sjpyh/FF85sdPAtlsbgMEIkmrgt rLOCw0gvdMHB1JV2ES3yOJwLBfWlPbkB7yxBL5/6EskjH0clE2Tjxlkj/RI8VJBVNfBd 2EY0N3nrsB7ycr//5+UkpRqQN2Z/rtzy5HnA9ILJm4/9/rvTl7/BUZqFN7eYJK8/jvCG gkmPNFLJPhKZiOsTSgak2INqfWKIN/eU9Ij+xwq46NCqNfTPxH5nUTZ3e4iSG7w0WQIz veS5sFCGdxWA66eo6bodZMV3XEvGhz8jD2iQia/XIRka1DZphlkYkhPfhdQ0S0OW6UNR cZ1w== 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=+GY3oCb8k4ZoxDmYR0zizW+h7H+4Er+voGLPiRHg8M8=; b=CpIrMURYKz7Zmeqaw3a6gjWx3iD6VMIRzc+zfh//F5QkwPeN0/W/uMZCXHSEAgX3X4 lldVSdeQ72/QinT+3jjOEPf0evG5WZjbAKAufysV3yWzfLal818oPw0MtB+gptlm3/Nx KLH+NIHCSG/oROzmKPxLEgDWRnMQ77tjUqLvZ48iJkIo5xuu/cJFvc/AZRKnxXB5pInl usMO3XUeDGiI3uwMJXF6HjX4+2xudqqTX+A5qYiMLKQ73K5uIaRmBkE8lATKPDheCRT+ G/JJ2mOR74FOYs+9UJjWhC3Adf/cgLrpKYDTI8/362b/8Xl2KdiXWMbXH39f0+HniI1H zODg== X-Gm-Message-State: AOAM533EQFhPu4q7RMpihUTJ9V7kPq1x+Shwo2IpB5UN4J+XXH3uTCY5 DQ8FlgJ2pnseeXW1pv0mT4liRBrk4OGmGL8z8NI= X-Google-Smtp-Source: ABdhPJzRapl46s0lFpw2Nt19ca5Rav7hgzuMh0a2e39z81FiHo9a5+iizMErLv3laisFfPSWpXKDA+tJ+Wqdm+Ow3go= X-Received: by 2002:ac8:4b63:: with SMTP id g3mr4424717qts.171.1590823201227; Sat, 30 May 2020 00:20:01 -0700 (PDT) MIME-Version: 1.0 References: <159076794319.1387573.8722376887638960093.stgit@firesoul> <159076798566.1387573.8417040652693679408.stgit@firesoul> In-Reply-To: <159076798566.1387573.8417040652693679408.stgit@firesoul> From: Andrii Nakryiko Date: Sat, 30 May 2020 00:19:50 -0700 Message-ID: Subject: Re: [PATCH bpf-next RFC 2/3] bpf: devmap dynamic map-value storage area based on BTF To: Jesper Dangaard Brouer Cc: David Ahern , bpf , Networking , Daniel Borkmann , Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Fri, May 29, 2020 at 8:59 AM Jesper Dangaard Brouer wrote: > > The devmap map-value can be read from BPF-prog side, and could be used for a > storage area per device. This could e.g. contain info on headers that need If BPF program needs a storage area per device, why can't it just use a separate map or just plain array (both keyed by ifindex) to store whatever it needs per-device? It's not clear why this flexibility and complexity is needed from the description above. > to be added when packet egress this device. > > This patchset adds a dynamic storage member to struct bpf_devmap_val. More > importantly the struct bpf_devmap_val is made dynamic via leveraging and > requiring BTF for struct sizes above 4. The only mandatory struct member is > 'ifindex' with a fixed offset of zero. > > Signed-off-by: Jesper Dangaard Brouer > --- > kernel/bpf/devmap.c | 216 ++++++++++++++++++++++++++++++++++++++++++++------- > 1 file changed, 185 insertions(+), 31 deletions(-) > [...]