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=-17.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 100F3C433ED for ; Mon, 26 Apr 2021 23:20:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CC1B561029 for ; Mon, 26 Apr 2021 23:20:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232235AbhDZXVA (ORCPT ); Mon, 26 Apr 2021 19:21:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51854 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232022AbhDZXU7 (ORCPT ); Mon, 26 Apr 2021 19:20:59 -0400 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2BB3C061574; Mon, 26 Apr 2021 16:20:16 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id p202so23357953ybg.8; Mon, 26 Apr 2021 16:20:16 -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=ragf3pBBuOEv+S1+l8phR3UOvi6C6PkqHckvqRYzvXY=; b=UK7IhNV1heUyIiPLGQUdXqP1iNOhkcz769U45fdE85RdnUk2FAjb8aW+W1AmVMSvuf EZiT5yhc9Jtm4IHvlZAiHGqo+ugl8OS3FiXv6MkU6dLvmif+V5Qjr0M+P2ZK8dkPLC0+ 6cHoINCbovh6Y/r0IiKjijjnw/+wWXPdGNABIN0n6lniXrXHKWfEkSFgKhTeWuzBduHt Y1ZMWNBzrPlOgcPp4TUp5eftd3GAnnthHKBN6BYwtV4ZQ9+6nn/en0CcXYQCJrGveY+S o/nTPRsqLtTvNJsGAynEak50S3Kc3E8cBtiRbwPfZMa40wGoHvRaOaHCOxCUZpQMQqWB 8Iig== 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=ragf3pBBuOEv+S1+l8phR3UOvi6C6PkqHckvqRYzvXY=; b=b41xCATx9kPMrhwd5GYwm41PN5vhHK0Q7x4uxa71y44FrFgfOEnWlR3SvEAxBFfvrM cIv0Q2JFoNcphdkxiCmnrDcGYMwdoQ/jGuVvxdVH5lbptdYBpnRauIApMlT//Z2SMS++ CW1SHhHstUqcYSi4/xh1khT+171IZVxJGaKenOEFq6Ucw+Zyy14F7ZCbqUnXPEZg9GIX jWIMgnK3ZoAhi1uEjVBQPt6LTURoYdRAiZID2yQLh9DDJzVpFJ+h+HK6/YX0quxB+UX1 3NYzQH4SNhNjjW9Qyq4QOTxwY9LnYZylhhBsIlc7Bs10o6Dh1Zlu4hPATKlZAhzDJtiB JUgg== X-Gm-Message-State: AOAM531+Nj5gEMBLEQgi869fPVLMtEfx567G+Yj2HkvH6KL/HPUERw92 iFqMCBgo9Nmzocgv+UW1cYf8ZQoNB8nnK5SQxgc= X-Google-Smtp-Source: ABdhPJxxx6uaPeIb83QO/9C/e3b9O2PSHVMqC27f7E+0oQ3+5OTLmYpDmFNq+ECvYhiV9fWDhEuc4qgvehmposIQaYU= X-Received: by 2002:a25:c4c5:: with SMTP id u188mr28538624ybf.425.1619479216354; Mon, 26 Apr 2021 16:20:16 -0700 (PDT) MIME-Version: 1.0 References: <20210426202240.518961-1-memxor@gmail.com> In-Reply-To: <20210426202240.518961-1-memxor@gmail.com> From: Andrii Nakryiko Date: Mon, 26 Apr 2021 16:20:04 -0700 Message-ID: Subject: Re: [PATCH] libbpf: export inline helpers as symbols for xsk To: Kumar Kartikeya Dwivedi Cc: bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Jonathan Lemon , "David S. Miller" , Jakub Kicinski , Jesper Dangaard Brouer , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Networking Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Mon, Apr 26, 2021 at 1:22 PM Kumar Kartikeya Dwivedi wrote: > > This helps people writing language bindings to not have to rewrite C > wrappers for inline functions in the headers. We force inline the > definition from the header for C and C++ consumers, but also export a > symbol in the library for others. This keeps the performance > advantages similar to using static inline, while also allowing tools > like Rust's bindgen to generate wrappers for the functions. > > Also see > https://lore.kernel.org/bpf/CAJ8uoz0QqR97qEYYK=VVCE9A=V=k2tKnH6wNM48jeak2RAmL0A@mail.gmail.com/ > for some context. > > Also see https://github.com/xdp-project/xdp-tools/pull/97 for more > discussion on the same. > > extern inline is used as it's slightly better since it warns when an > inline definition is missing. > > The fvisibility attribute goes on the inline definition, as essentially > it acts as a declaration for the function, while the extern inline > declaration ends up acting as a definition. > > Signed-off-by: Kumar Kartikeya Dwivedi > --- xsk is moving into libxdp, why not do this there, instead of exporting a lot of symbols that we'll be deprecating very soon. It will also incentivise customers to make a move more promptly. Bjorn, Magnus, what's the status of libxsk in libxdp? > tools/lib/bpf/libbpf.map | 16 ++++++++++++++ > tools/lib/bpf/xsk.c | 24 +++++++++++++++++++++ > tools/lib/bpf/xsk.h | 45 +++++++++++++++++++++++----------------- > 3 files changed, 66 insertions(+), 19 deletions(-) > [...]