From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 58B5A2C39 for ; Tue, 26 Mar 2019 03:22:34 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2019 19:22:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="143803307" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.110.206]) by FMSMGA003.fm.intel.com with ESMTP; 25 Mar 2019 19:22:31 -0700 Date: Tue, 26 Mar 2019 10:18:12 +0800 From: Ye Xiaolong To: Luca Boccassi Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" Message-ID: <20190326021812.GB48057@intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v1 1/6] 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: Tue, 26 Mar 2019 02:22:34 -0000 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) += >> > > > > > -lrte_pmd_af_packet >> > > > > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_XDP) += >> > > > > > -lrte_pmd_af_xdp >> > > > > > -lelf -lbpf >> > > > > >> > > > > Are symbols from libelf being used by the PMD? >> > > > >> > > > Hmm, it is a leftover of RFC, libelf is no longer needed in >> > > > this >> > > > version, will >> > > > remove it in next version. >> > > > >> > > >> > > Correction, libelf is needed for libbpf, so we still need to keep >> > > it. >> > >> > 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? >> > >> >> 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. >> >> /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' >> >> Thanks, >> Xiaolong > >Looking at that list, at least the very first symbol is not used by a >public header, but internally in libbpf: > >$ grep -r elf_nextscn >libbpf.c: while ((scn = elf_nextscn(elf, scn)) != NULL) { > >https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/lib/bpf/libbpf.c#n793 > >None of those symbols are used from the public headers: > >$ grep elf_ bpf.h libbpf.h btf.h >$ > >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. As it may need sometime for kernel community to handle the libbpf's Makefile, 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? Thanks, Xiaolong > >-- >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 7BDC9A05D3 for ; Tue, 26 Mar 2019 03:22:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 665E02C60; Tue, 26 Mar 2019 03:22:35 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 58B5A2C39 for ; Tue, 26 Mar 2019 03:22:34 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2019 19:22:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,271,1549958400"; d="scan'208";a="143803307" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.110.206]) by FMSMGA003.fm.intel.com with ESMTP; 25 Mar 2019 19:22:31 -0700 Date: Tue, 26 Mar 2019 10:18:12 +0800 From: Ye Xiaolong To: Luca Boccassi Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" Message-ID: <20190326021812.GB48057@intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH v1 1/6] 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: <20190326021812.gBDS2MoTX5eQmn8zeL1JQU06kI7hOFc4ufQDK7VCayM@z> 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) += >> > > > > > -lrte_pmd_af_packet >> > > > > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_XDP) += >> > > > > > -lrte_pmd_af_xdp >> > > > > > -lelf -lbpf >> > > > > >> > > > > Are symbols from libelf being used by the PMD? >> > > > >> > > > Hmm, it is a leftover of RFC, libelf is no longer needed in >> > > > this >> > > > version, will >> > > > remove it in next version. >> > > > >> > > >> > > Correction, libelf is needed for libbpf, so we still need to keep >> > > it. >> > >> > 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? >> > >> >> 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. >> >> /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' >> >> Thanks, >> Xiaolong > >Looking at that list, at least the very first symbol is not used by a >public header, but internally in libbpf: > >$ grep -r elf_nextscn >libbpf.c: while ((scn = elf_nextscn(elf, scn)) != NULL) { > >https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/lib/bpf/libbpf.c#n793 > >None of those symbols are used from the public headers: > >$ grep elf_ bpf.h libbpf.h btf.h >$ > >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. As it may need sometime for kernel community to handle the libbpf's Makefile, 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? Thanks, Xiaolong > >-- >Kind regards, >Luca Boccassi