From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id DBF2B1B3A5 for ; Wed, 3 Apr 2019 14:16:27 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id q1so21037470wrp.0 for ; Wed, 03 Apr 2019 05:16:27 -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=x/kZbK1AMe8gvnf/tfPefa3WtgjZRTVScAMjC3ej4uo=; b=peU5meqUTQ8xg7KVwglLqARmD0SWBdqTWLdDriTUx2kYwlEE/qhifN0t7RwsIrxVS4 m8nTebXPV0BIGTvaUSZHWanVHiXxh2cF97RsrIE6QEwqpiq98hXdikqOWsga6LkbbSmU 4uRxWfADEuzRN3d8M5UQVlSA4jSBHA/T8u15mVUvISm9yN6Xg/6DsCr9s29vaTiKR2qX wgGotZTL793ym1HJvy3WpgW7b7MqXUV5Xh73OvH1IvWgnqAvVBiTfYLiFjHcQSWK3nOR zll86aI7TE/ZvQHNU82kCmX7uZjtQP2yybbN93gUZxg+2aqAdpIqDbsHeukHrpeo0YqP kJBA== X-Gm-Message-State: APjAAAXfSasCPE7qqkVxzhMUzPUx7F5ls656kMgBh1/RqXRtDGzPBrUZ ExQUU1/Sx+82gSiHLTPQHcQ= X-Google-Smtp-Source: APXvYqxozZZaNS3AR2KUZxQcEmtJgJVn+g59gmSwEulp/FMo1oVFqgDjlxSpEEWG3MMZC8LFdBxMcA== X-Received: by 2002:a5d:6384:: with SMTP id p4mr48166429wru.208.1554293787494; Wed, 03 Apr 2019 05:16:27 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:250:b6ff:feb7:bd60]) by smtp.gmail.com with ESMTPSA id t14sm14277159wmi.16.2019.04.03.05.16.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 05:16:25 -0700 (PDT) Message-ID: From: Luca Boccassi To: Ferruh Yigit , Ye Xiaolong Cc: dev@dpdk.org, Karlsson Magnus , Topel Bjorn Date: Wed, 03 Apr 2019 13:16:25 +0100 In-Reply-To: <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> 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> <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> 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 12:16:28 -0000 On Wed, 2019-04-03 at 12:35 +0100, Luca Boccassi wrote: > 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/?i= d=3D379e2014c95b > > >=20 > > >=20 > >=20 > > Good to have this one. But again it is in BPF tree and it won't be > > in > > 5.1. >=20 > 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. >=20 > Bjorn and Magnus, any chance the above makefile install fix could be > sent for inclusion in 5.1-rc4? Actually the bpf tree was already merged in the net tree a couple of days ago. As far as I understand from the process, this should mean that this fix should be set for inclusion in Linus' tree in time for 5.1-rc4: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit?id=3D3= 79e2014c95b7a454713da822b8ef4ec51ab8a75 --=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 83818A0679 for ; Wed, 3 Apr 2019 14:16:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 792491B3A6; Wed, 3 Apr 2019 14:16:29 +0200 (CEST) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id DBF2B1B3A5 for ; Wed, 3 Apr 2019 14:16:27 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id q1so21037470wrp.0 for ; Wed, 03 Apr 2019 05:16:27 -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=x/kZbK1AMe8gvnf/tfPefa3WtgjZRTVScAMjC3ej4uo=; b=peU5meqUTQ8xg7KVwglLqARmD0SWBdqTWLdDriTUx2kYwlEE/qhifN0t7RwsIrxVS4 m8nTebXPV0BIGTvaUSZHWanVHiXxh2cF97RsrIE6QEwqpiq98hXdikqOWsga6LkbbSmU 4uRxWfADEuzRN3d8M5UQVlSA4jSBHA/T8u15mVUvISm9yN6Xg/6DsCr9s29vaTiKR2qX wgGotZTL793ym1HJvy3WpgW7b7MqXUV5Xh73OvH1IvWgnqAvVBiTfYLiFjHcQSWK3nOR zll86aI7TE/ZvQHNU82kCmX7uZjtQP2yybbN93gUZxg+2aqAdpIqDbsHeukHrpeo0YqP kJBA== X-Gm-Message-State: APjAAAXfSasCPE7qqkVxzhMUzPUx7F5ls656kMgBh1/RqXRtDGzPBrUZ ExQUU1/Sx+82gSiHLTPQHcQ= X-Google-Smtp-Source: APXvYqxozZZaNS3AR2KUZxQcEmtJgJVn+g59gmSwEulp/FMo1oVFqgDjlxSpEEWG3MMZC8LFdBxMcA== X-Received: by 2002:a5d:6384:: with SMTP id p4mr48166429wru.208.1554293787494; Wed, 03 Apr 2019 05:16:27 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:250:b6ff:feb7:bd60]) by smtp.gmail.com with ESMTPSA id t14sm14277159wmi.16.2019.04.03.05.16.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 05:16:25 -0700 (PDT) Message-ID: From: Luca Boccassi To: Ferruh Yigit , Ye Xiaolong Cc: dev@dpdk.org, Karlsson Magnus , Topel Bjorn Date: Wed, 03 Apr 2019 13:16:25 +0100 In-Reply-To: <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> 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> <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> 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: <20190403121625.qgap9YIA6hlhOZ3AILAvsbLscnXN3R5SbX4saMkEQsg@z> On Wed, 2019-04-03 at 12:35 +0100, Luca Boccassi wrote: > 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/?i= d=3D379e2014c95b > > >=20 > > >=20 > >=20 > > Good to have this one. But again it is in BPF tree and it won't be > > in > > 5.1. >=20 > 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. >=20 > Bjorn and Magnus, any chance the above makefile install fix could be > sent for inclusion in 5.1-rc4? Actually the bpf tree was already merged in the net tree a couple of days ago. As far as I understand from the process, this should mean that this fix should be set for inclusion in Linus' tree in time for 5.1-rc4: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit?id=3D3= 79e2014c95b7a454713da822b8ef4ec51ab8a75 --=20 Kind regards, Luca Boccassi