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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 4DBDBCA9EC3 for ; Thu, 31 Oct 2019 08:03:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1BAA620873 for ; Thu, 31 Oct 2019 08:03:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="VV2VdF/N" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726864AbfJaIDI (ORCPT ); Thu, 31 Oct 2019 04:03:08 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:46396 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726827AbfJaIDI (ORCPT ); Thu, 31 Oct 2019 04:03:08 -0400 Received: by mail-qk1-f196.google.com with SMTP id e66so5982407qkf.13; Thu, 31 Oct 2019 01:03:08 -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:content-transfer-encoding; bh=XHH5Q1E0KLWmxD8JWZZyl3lVQ4k4CZTfpkZ3GVSKivg=; b=VV2VdF/Nv9gspv/jQ/9mC2d6jQ8Olv+eZ081oLcIrWq1+orTpxOt+jYkncGoiVzKtm 92N9yR6EQYm9jzRO/QDaYu8BQIt+K6KCC07Xo8h9T414HqtoOwU50W0Q3tDsAipitulj kvIyTC+Ek8/EWYMpY1wBBxNkbUzjAXVGYCF7KAG5r/FIHolZyk76KzSTE6jPxOGLrof+ okOb3Ei2fOkFGu9sMMRn9TiX2q3iI8Q6HZJZ2qp+wZbzBiY1Ymz1Uaz8g0hYWH6xbnpk axcUHZnkZ5bys3iYWRSzl4yntjH1V4qqWVoGkeFLVXM0j3jzg+oGkg2BOVyatGEOTrNT Xi9w== 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:content-transfer-encoding; bh=XHH5Q1E0KLWmxD8JWZZyl3lVQ4k4CZTfpkZ3GVSKivg=; b=DCpft+YSJkoZeAh8SbnkxIC5RPErgoWmCxtnUEsgAP00d56OeI2eyg2b3Y3IFtLNtv 5OUjIKpL8GCqrsGXmldvjcxCnAUQWp+//SFmiy/K+AjFFxLCsjFo77lOMTkJ90knBy/h AIyqg+Gqc76jbnledLMUpRUkc38kndALpnF8TCfIgt3wSWy5MvThf4XNvOfW6xPP6Zub yF/IC1wmAPkmgsP5f+aWrP/FNGWTEZSeAFP/5JlTlImhHxy66QZOFmz+TP33tfS02ebA OycD8PSpxAeiDgqRVvGJGjEfkB1MCHt5vwtL/0PoYO7ClLx3oNWqWuMiGHvGHORVg6mb oa3g== X-Gm-Message-State: APjAAAWZFJczebmkF6R5lWNytFwKsd71CI0+0n2LxgVry1gk8VfLBqWJ ovLjuejs9bZXcuJ5XS4ENzh/ZpatmjSKaqFsidI= X-Google-Smtp-Source: APXvYqz1FSY4r0N2EXGvNQjgSalH60uxTPak8AluAaHp3Ww19sU2qPkPUItzxu78+m6Xv81WS9NUXnPBIdRy6PzHf8g= X-Received: by 2002:a37:4a14:: with SMTP id x20mr4134973qka.333.1572508987553; Thu, 31 Oct 2019 01:03:07 -0700 (PDT) MIME-Version: 1.0 References: <1571995035-21889-1-git-send-email-magnus.karlsson@intel.com> <87tv7qpdbt.fsf@toke.dk> In-Reply-To: From: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= Date: Thu, 31 Oct 2019 09:02:56 +0100 Message-ID: Subject: Re: [PATCH bpf-next v3] libbpf: fix compatibility for kernels without need_wakeup To: Magnus Karlsson Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Magnus Karlsson , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Alexei Starovoitov , Daniel Borkmann , Network Development , Jonathan Lemon , bpf , degeneloy@gmail.com, John Fastabend Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, 31 Oct 2019 at 08:17, Magnus Karlsson w= rote: > > On Wed, Oct 30, 2019 at 2:36 PM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > > > Magnus Karlsson writes: > > > > > When the need_wakeup flag was added to AF_XDP, the format of the > > > XDP_MMAP_OFFSETS getsockopt was extended. Code was added to the > > > kernel to take care of compatibility issues arrising from running > > > applications using any of the two formats. However, libbpf was > > > not extended to take care of the case when the application/libbpf > > > uses the new format but the kernel only supports the old > > > format. This patch adds support in libbpf for parsing the old > > > format, before the need_wakeup flag was added, and emulating a > > > set of static need_wakeup flags that will always work for the > > > application. > > > > Hi Magnus > > > > While you're looking at backwards compatibility issues with xsk: libbpf > > currently fails to compile on a system that has old kernel headers > > installed (this is with kernel-headers 5.3): > > > > $ echo "#include " | gcc -x c - > > In file included from :1: > > /usr/include/bpf/xsk.h: In function =E2=80=98xsk_ring_prod__needs_wakeu= p=E2=80=99: > > /usr/include/bpf/xsk.h:82:21: error: =E2=80=98XDP_RING_NEED_WAKEUP=E2= =80=99 undeclared (first use in this function) > > 82 | return *r->flags & XDP_RING_NEED_WAKEUP; > > | ^~~~~~~~~~~~~~~~~~~~ > > /usr/include/bpf/xsk.h:82:21: note: each undeclared identifier is repor= ted only once for each function it appears in > > /usr/include/bpf/xsk.h: In function =E2=80=98xsk_umem__extract_addr=E2= =80=99: > > /usr/include/bpf/xsk.h:173:16: error: =E2=80=98XSK_UNALIGNED_BUF_ADDR_M= ASK=E2=80=99 undeclared (first use in this function) > > 173 | return addr & XSK_UNALIGNED_BUF_ADDR_MASK; > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /usr/include/bpf/xsk.h: In function =E2=80=98xsk_umem__extract_offset= =E2=80=99: > > /usr/include/bpf/xsk.h:178:17: error: =E2=80=98XSK_UNALIGNED_BUF_OFFSET= _SHIFT=E2=80=99 undeclared (first use in this function) > > 178 | return addr >> XSK_UNALIGNED_BUF_OFFSET_SHIFT; > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > How would you prefer to handle this? A patch like the one below will fi= x > > the compile errors, but I'm not sure it makes sense semantically? > > Thanks Toke for finding this. Of course it should be possible to > compile this on an older kernel, but without getting any of the newer > functionality that is not present in that older kernel. Is the plan to support source compatibility for the headers only, or the whole the libbpf itself? Is the usecase here, that you've built libbpf.so with system headers X, and then would like to use the library on a system with older system headers X~10? XDP sockets? BTF?