From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 8C3D31B1F9 for ; Wed, 3 Apr 2019 13:35:09 +0200 (CEST) Received: by mail-wm1-f67.google.com with SMTP id z24so7815697wmi.5 for ; Wed, 03 Apr 2019 04:35:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=Cqc6XizoMAZrfx5jEmjG/cnFaf+gIBQBXjLE1PUlP+c=; b=NRRruuOUBpeuEaKHA7t2McxhPKHHoE/NNF5oMqNBM3GpTtQQpvrAxpmelVaFRWnDEa 1OMapI8HB+5RLwRB5DpCVRfyZmLKghL8ib0MIwY9R+481zn6zjyM5tUzIuY6paqb68uw uDDOVV4Bc7dhVZV7rf6pnOra9zbVx5bH0/9kA7Dfes8GsaMWtDKFYE/jTen2u8reagTr 7pWEhIRWY+mNB/eVRk4UQZ8q5XirgvYog75NTEih1MASNgtpXon8y9Y55UTC5ru6rxxI CoKSvWPA1T6MwNoc/6ZUX9+/jjcwwxzpI4+Lnf0EvpD//dsb9LUvu13z8lmiyvh0Jn41 eGdQ== X-Gm-Message-State: APjAAAVyCvhMxdyl16dIGnydnYiozcfu6VojjM7AvivG1/LuioTAKS7+ i91Icus7c01F1j6XPb62c9A= X-Google-Smtp-Source: APXvYqzsDvuEdS/nFvysfSiCrc4+W5Mhf8Z8IwSEd1Ulalutf+t/+vN18qz3QSkQJvB6Oj4Up/tgRw== X-Received: by 2002:a1c:7611:: with SMTP id r17mr140514wmc.98.1554291309028; Wed, 03 Apr 2019 04:35:09 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:250:b6ff:feb7:bd60]) by smtp.gmail.com with ESMTPSA id y127sm15222274wmg.29.2019.04.03.04.35.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 04:35:08 -0700 (PDT) Message-ID: <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> From: Luca Boccassi To: Ferruh Yigit , Ye Xiaolong Cc: dev@dpdk.org, Karlsson Magnus , Topel Bjorn Date: Wed, 03 Apr 2019 12:35:07 +0100 In-Reply-To: <80c81c0c-cf64-59f8-a592-26cd865fbd89@intel.com> References: <20190301080947.91086-1-xiaolong.ye@intel.com> <20190402154653.711-1-xiaolong.ye@intel.com> <20190402154653.711-2-xiaolong.ye@intel.com> <20190403095939.GA32340@intel.com> <56ce5855b02d47a085a8d36451561c400f0b039c.camel@debian.org> <0dde8c20e9992047f29d39ad45dcf511244a5297.camel@debian.org> <80c81c0c-cf64-59f8-a592-26cd865fbd89@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v9 1/1] net/af_xdp: introduce AF XDP PMD driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 11:35:09 -0000 On Wed, 2019-04-03 at 12:18 +0100, Ferruh Yigit wrote: > On 4/3/2019 11:42 AM, Luca Boccassi wrote: > > On Wed, 2019-04-03 at 11:36 +0100, Luca Boccassi wrote: > > > On Wed, 2019-04-03 at 17:59 +0800, Ye Xiaolong wrote: > > > > Hi, Luca > > > >=20 > > > > On 04/02, Luca Boccassi wrote: > > > > > On Tue, 2019-04-02 at 23:46 +0800, Xiaolong Ye wrote: > > > > > > diff --git a/drivers/net/af_xdp/Makefile > > > > > > b/drivers/net/af_xdp/Makefile > > > > > > new file mode 100644 > > > > > > index 000000000..8343e3016 > > > > > > --- /dev/null > > > > > > +++ b/drivers/net/af_xdp/Makefile > > > > > > @@ -0,0 +1,32 @@ > > > > > > +# SPDX-License-Identifier: BSD-3-Clause > > > > > > +# Copyright(c) 2019 Intel Corporation > > > > > > + > > > > > > +include $(RTE_SDK)/mk/rte.vars.mk > > > > > > + > > > > > > +# > > > > > > +# library name > > > > > > +# > > > > > > +LIB =3D librte_pmd_af_xdp.a > > > > > > + > > > > > > +EXPORT_MAP :=3D rte_pmd_af_xdp_version.map > > > > > > + > > > > > > +LIBABIVER :=3D 1 > > > > > > + > > > > > > +CFLAGS +=3D -O3 > > > > > > + > > > > > > +# require kernel version >=3D v5.1-rc1 > > > > > > +CFLAGS +=3D -I$(RTE_KERNELDIR)/tools/include > > > > > > +CFLAGS +=3D -I$(RTE_KERNELDIR)/tools/lib/bpf > > > > >=20 > > > > > Sorry for not noticing this before, but doesn't this require > > > > > the > > > > > full > > > > > kernel tree rather than just the typical headers package? > > > > > Requiring > > > > > the > > > > > full kernel tree to be available at build time will make this > > > > > unbuildable on distros that still use makefiles, like RHEL > > > > > and > > > > > SUSE. At > > > > > least on Debian and Ubuntu, the kernel headers packages > > > > > distributed > > > > > do > > > > > not include the full kernel tree, only the headers, so > > > > > there's no > > > > > tools/lib or tools/include. > > > >=20 > > > > Currently we do have dependencies on the kernel src tree, as > > > > xsk.h > > > > and > > > > asm/barrier wouldn't be installed by libbpf, so before libbpf > > > > handles > > > > these > > > > properly, can we keep the current RTE_KERNELDIR in Makefile for > > > > now, > > > > and mention > > > > the dependencies in document, also suggest users to config > > > > RTE_KERNELDIR to correct > > > > kernel src tree if they want to use af_xdp pmd? > > > >=20 > > > > Something like: > > > >=20 > > > > dependencies: > > > > - kernel source code (>=3D v5.1-rc1) > > > > - build libbfp and install > > > >=20 > > > > Thanks, > > > > Xiaolong > > >=20 > > > asm/barrier.h is installed by the kernel headers packages so it > > > would > > > be fine (although not ideal) and not need the full source tree. > > > xsk.h is a bit more worrying, as it looks like an internal header > > > from > > > here. > > >=20 > > > Is it really necessary for external applications to use an > > > internal- > > > only header and a kernel header to be able to use libbpf? > >=20 > > Actually, xsk.h is now installed by the library makefile: > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id= =3D379e2014c95b > >=20 >=20 > Good to have this one. But again it is in BPF tree and it won't be in > 5.1. It looks like a small and required bug fix to me, and 5.1 is still in RC state, so perhaps there's still time. Bjorn and Magnus, any chance the above makefile install fix could be sent for inclusion in 5.1-rc4? > I suggested changing code as following for now, it would help to keep > changes > small when above patch merged into kernel: > CFLAGS +=3D -I$(RTE_KERNELDIR)/tools/lib [in makefile] > #include [in .c file] >=20 > > So the full kernel source tree is no longer required. > >=20 > > Is asm/barrier.h really required? Isn't there an userspace > > alternative? >=20 > The 'asm/barrier.h' in the kernel headers and the > 'tools/include/asm/barrier.h' > looks different, the one in the kernel source has dependency to other > kernel > headers. >=20 > I wonder same thing, what is used from 'tools/include/asm/barrier.h' > and if it > can be avoided. The one in tools/include also is GPL-2.0 only so it cannot be included from the PMD, which is BSD-3-clause only (and it recursively includes the other arch-specific kernel headers) > Anyway, as Xiaolong mentioned, following is working, can it work from > a distro > point of view: > - get kernel source code (>=3D v5.1-rc1) > - build libbfp and install > - set 'RTE_KERNELDIR' to point kernel source path > - build dpdk with af_xdp enabled As long as the full kernel tree is required, we cannot enable it in Debian and Ubuntu - we can't have it at build time on the build workers, and also there's the licensing problem. > > Also, the license in asm/barrier.h is GPL-2.0 only. It is not a > > userspace header so it is not covered by the userspace exception, > > which > > means at the very least the af_xdp PMD shared object is also > > licensed > > under GPL-2.0 only, isn't it? > >=20 >=20 >=20 --=20 Kind regards, Luca Boccassi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 93A02A0679 for ; Wed, 3 Apr 2019 13:35:11 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 371861B1FC; Wed, 3 Apr 2019 13:35:10 +0200 (CEST) Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 8C3D31B1F9 for ; Wed, 3 Apr 2019 13:35:09 +0200 (CEST) Received: by mail-wm1-f67.google.com with SMTP id z24so7815697wmi.5 for ; Wed, 03 Apr 2019 04:35:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=Cqc6XizoMAZrfx5jEmjG/cnFaf+gIBQBXjLE1PUlP+c=; b=NRRruuOUBpeuEaKHA7t2McxhPKHHoE/NNF5oMqNBM3GpTtQQpvrAxpmelVaFRWnDEa 1OMapI8HB+5RLwRB5DpCVRfyZmLKghL8ib0MIwY9R+481zn6zjyM5tUzIuY6paqb68uw uDDOVV4Bc7dhVZV7rf6pnOra9zbVx5bH0/9kA7Dfes8GsaMWtDKFYE/jTen2u8reagTr 7pWEhIRWY+mNB/eVRk4UQZ8q5XirgvYog75NTEih1MASNgtpXon8y9Y55UTC5ru6rxxI CoKSvWPA1T6MwNoc/6ZUX9+/jjcwwxzpI4+Lnf0EvpD//dsb9LUvu13z8lmiyvh0Jn41 eGdQ== X-Gm-Message-State: APjAAAVyCvhMxdyl16dIGnydnYiozcfu6VojjM7AvivG1/LuioTAKS7+ i91Icus7c01F1j6XPb62c9A= X-Google-Smtp-Source: APXvYqzsDvuEdS/nFvysfSiCrc4+W5Mhf8Z8IwSEd1Ulalutf+t/+vN18qz3QSkQJvB6Oj4Up/tgRw== X-Received: by 2002:a1c:7611:: with SMTP id r17mr140514wmc.98.1554291309028; Wed, 03 Apr 2019 04:35:09 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:250:b6ff:feb7:bd60]) by smtp.gmail.com with ESMTPSA id y127sm15222274wmg.29.2019.04.03.04.35.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 04:35:08 -0700 (PDT) Message-ID: <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> From: Luca Boccassi To: Ferruh Yigit , Ye Xiaolong Cc: dev@dpdk.org, Karlsson Magnus , Topel Bjorn Date: Wed, 03 Apr 2019 12:35:07 +0100 In-Reply-To: <80c81c0c-cf64-59f8-a592-26cd865fbd89@intel.com> References: <20190301080947.91086-1-xiaolong.ye@intel.com> <20190402154653.711-1-xiaolong.ye@intel.com> <20190402154653.711-2-xiaolong.ye@intel.com> <20190403095939.GA32340@intel.com> <56ce5855b02d47a085a8d36451561c400f0b039c.camel@debian.org> <0dde8c20e9992047f29d39ad45dcf511244a5297.camel@debian.org> <80c81c0c-cf64-59f8-a592-26cd865fbd89@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v9 1/1] net/af_xdp: introduce AF XDP PMD driver X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190403113507.woa3gNPD9Lc1fYzBTr5dWzpPnDNnjzCg0D_UCFq3l8g@z> On Wed, 2019-04-03 at 12:18 +0100, Ferruh Yigit wrote: > On 4/3/2019 11:42 AM, Luca Boccassi wrote: > > On Wed, 2019-04-03 at 11:36 +0100, Luca Boccassi wrote: > > > On Wed, 2019-04-03 at 17:59 +0800, Ye Xiaolong wrote: > > > > Hi, Luca > > > >=20 > > > > On 04/02, Luca Boccassi wrote: > > > > > On Tue, 2019-04-02 at 23:46 +0800, Xiaolong Ye wrote: > > > > > > diff --git a/drivers/net/af_xdp/Makefile > > > > > > b/drivers/net/af_xdp/Makefile > > > > > > new file mode 100644 > > > > > > index 000000000..8343e3016 > > > > > > --- /dev/null > > > > > > +++ b/drivers/net/af_xdp/Makefile > > > > > > @@ -0,0 +1,32 @@ > > > > > > +# SPDX-License-Identifier: BSD-3-Clause > > > > > > +# Copyright(c) 2019 Intel Corporation > > > > > > + > > > > > > +include $(RTE_SDK)/mk/rte.vars.mk > > > > > > + > > > > > > +# > > > > > > +# library name > > > > > > +# > > > > > > +LIB =3D librte_pmd_af_xdp.a > > > > > > + > > > > > > +EXPORT_MAP :=3D rte_pmd_af_xdp_version.map > > > > > > + > > > > > > +LIBABIVER :=3D 1 > > > > > > + > > > > > > +CFLAGS +=3D -O3 > > > > > > + > > > > > > +# require kernel version >=3D v5.1-rc1 > > > > > > +CFLAGS +=3D -I$(RTE_KERNELDIR)/tools/include > > > > > > +CFLAGS +=3D -I$(RTE_KERNELDIR)/tools/lib/bpf > > > > >=20 > > > > > Sorry for not noticing this before, but doesn't this require > > > > > the > > > > > full > > > > > kernel tree rather than just the typical headers package? > > > > > Requiring > > > > > the > > > > > full kernel tree to be available at build time will make this > > > > > unbuildable on distros that still use makefiles, like RHEL > > > > > and > > > > > SUSE. At > > > > > least on Debian and Ubuntu, the kernel headers packages > > > > > distributed > > > > > do > > > > > not include the full kernel tree, only the headers, so > > > > > there's no > > > > > tools/lib or tools/include. > > > >=20 > > > > Currently we do have dependencies on the kernel src tree, as > > > > xsk.h > > > > and > > > > asm/barrier wouldn't be installed by libbpf, so before libbpf > > > > handles > > > > these > > > > properly, can we keep the current RTE_KERNELDIR in Makefile for > > > > now, > > > > and mention > > > > the dependencies in document, also suggest users to config > > > > RTE_KERNELDIR to correct > > > > kernel src tree if they want to use af_xdp pmd? > > > >=20 > > > > Something like: > > > >=20 > > > > dependencies: > > > > - kernel source code (>=3D v5.1-rc1) > > > > - build libbfp and install > > > >=20 > > > > Thanks, > > > > Xiaolong > > >=20 > > > asm/barrier.h is installed by the kernel headers packages so it > > > would > > > be fine (although not ideal) and not need the full source tree. > > > xsk.h is a bit more worrying, as it looks like an internal header > > > from > > > here. > > >=20 > > > Is it really necessary for external applications to use an > > > internal- > > > only header and a kernel header to be able to use libbpf? > >=20 > > Actually, xsk.h is now installed by the library makefile: > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id= =3D379e2014c95b > >=20 >=20 > Good to have this one. But again it is in BPF tree and it won't be in > 5.1. It looks like a small and required bug fix to me, and 5.1 is still in RC state, so perhaps there's still time. Bjorn and Magnus, any chance the above makefile install fix could be sent for inclusion in 5.1-rc4? > I suggested changing code as following for now, it would help to keep > changes > small when above patch merged into kernel: > CFLAGS +=3D -I$(RTE_KERNELDIR)/tools/lib [in makefile] > #include [in .c file] >=20 > > So the full kernel source tree is no longer required. > >=20 > > Is asm/barrier.h really required? Isn't there an userspace > > alternative? >=20 > The 'asm/barrier.h' in the kernel headers and the > 'tools/include/asm/barrier.h' > looks different, the one in the kernel source has dependency to other > kernel > headers. >=20 > I wonder same thing, what is used from 'tools/include/asm/barrier.h' > and if it > can be avoided. The one in tools/include also is GPL-2.0 only so it cannot be included from the PMD, which is BSD-3-clause only (and it recursively includes the other arch-specific kernel headers) > Anyway, as Xiaolong mentioned, following is working, can it work from > a distro > point of view: > - get kernel source code (>=3D v5.1-rc1) > - build libbfp and install > - set 'RTE_KERNELDIR' to point kernel source path > - build dpdk with af_xdp enabled As long as the full kernel tree is required, we cannot enable it in Debian and Ubuntu - we can't have it at build time on the build workers, and also there's the licensing problem. > > Also, the license in asm/barrier.h is GPL-2.0 only. It is not a > > userspace header so it is not covered by the userspace exception, > > which > > means at the very least the af_xdp PMD shared object is also > > licensed > > under GPL-2.0 only, isn't it? > >=20 >=20 >=20 --=20 Kind regards, Luca Boccassi