From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Boccassi Subject: Re: [PATCH v1 1/6] net/af_xdp: introduce AF_XDP PMD driver Date: Tue, 26 Mar 2019 10:14:24 +0000 Message-ID: <9b875fc3d5597cd8e793a8ac7b40a8b7efad6e74.camel@debian.org> References: <20190301080947.91086-1-xiaolong.ye@intel.com> <20190301080947.91086-2-xiaolong.ye@intel.com> <20190302081407.GD100586@intel.com> <20190317033425.GA103486@intel.com> <1553429237.20876.3.camel@debian.org> <20190325024559.GB35864@intel.com> <20190326021812.GB48057@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" To: Ye Xiaolong Return-path: Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by dpdk.org (Postfix) with ESMTP id 6701D11A4 for ; Tue, 26 Mar 2019 11:14:26 +0100 (CET) Received: by mail-wm1-f65.google.com with SMTP id z6so2014569wmi.0 for ; Tue, 26 Mar 2019 03:14:26 -0700 (PDT) In-Reply-To: <20190326021812.GB48057@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 2019-03-26 at 10:18 +0800, Ye Xiaolong wrote: > On 03/25, Luca Boccassi wrote: > > On Mon, 2019-03-25 at 10:45 +0800, Ye Xiaolong wrote: > > > On 03/24, Luca Boccassi wrote: > > > > On Sun, 2019-03-17 at 11:34 +0800, Ye Xiaolong wrote: > > > > > On 03/02, Ye Xiaolong wrote: > > > > > > > > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) +=3D > > > > > > > > -lrte_pmd_af_packet > > > > > > > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_XDP) +=3D > > > > > > > > -lrte_pmd_af_xdp > > > > > > > > -lelf -lbpf > > > > > > >=20 > > > > > > > Are symbols from libelf being used by the PMD? > > > > > >=20 > > > > > > Hmm, it is a leftover of RFC, libelf is no longer needed in > > > > > > this > > > > > > version, will > > > > > > remove it in next version. > > > > > >=20 > > > > >=20 > > > > > Correction, libelf is needed for libbpf, so we still need to > > > > > keep > > > > > it.=20 > > > >=20 > > > > If libbpf needs libelf for its internal usage, it should be > > > > linked > > > > against it itself. Unless symbols from libelf are used in > > > > static > > > > functions defined in libbpf's public headers. Is this the case? > > > >=20 > > >=20 > > > Yes, that's the case. without the libelf, it would have build > > > error > > > as below, > > > and these symbols are used in static functions of libbpf. > > >=20 > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_nextscn' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_rawdata' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_memory' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `gelf_getrel' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_strptr' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_end' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_getscn' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_begin' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `gelf_getsym' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_version' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `gelf_getehdr' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `elf_getdata' > > > /usr/lib/gcc/x86_64-redhat- > > > linux/4.8.5/../../../../lib64/libbpf.so: > > > undefined reference to `gelf_getshdr' > > >=20 > > > Thanks, > > > Xiaolong > >=20 > > Looking at that list, at least the very first symbol is not used by > > a > > public header, but internally in libbpf: > >=20 > > $ grep -r elf_nextscn > > libbpf.c: while ((scn =3D elf_nextscn(elf, scn)) !=3D NULL) { > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/t= ools/lib/bpf/libbpf.c#n793 > >=20 > > None of those symbols are used from the public headers: > >=20 > > $ grep elf_ bpf.h libbpf.h btf.h > > $ > >=20 > > Therefore, this is an omission in libbpf's Makefile, as it must > > link > > against libelf. Please raise a ticket or send a patch upstream, and > > remove the -lelf from DPDK's makefiles. >=20 > As it may need sometime for kernel community to handle the libbpf's > Makefile,=20 > We may still need the -lelf for af_xdp pmd currently, I'll remove it > later after > libbpf correct to link against libelf. Is it acceptable? >=20 > Thanks, > Xiaolong Isn't the final version not out yet anyway till May? Can the fix be included before the release? --=20 Kind regards, Luca Boccassi