From mboxrd@z Thu Jan 1 00:00:00 1970 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 5FD8A2BF4 for ; Mon, 25 Mar 2019 11:42:29 +0100 (CET) Received: by mail-wm1-f65.google.com with SMTP id o10so1207166wmc.1 for ; Mon, 25 Mar 2019 03:42:29 -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=ycixQRSd2abu2LtZzFh71gCG9vLFuMhs4+F4NQDRsNs=; b=rI6u45V5FpP2PIy+4pQYHG6mQu3mxLJ7ZK9NeetFmit/Hl4p0r/eb7x5M1Rv/ar+2S +UD4W3knY80X96KlUY/V6turIUGZg7Sg4TaotiE7FxmQJhTNm0B4iW63oAW3+fVkmY5N P9EHTpsB5PSihtsbGQlw449uZrTzeJHo95rel1d38YvxD8lQpnk54PHqIqVTaT+p8Yl5 ivp0q5Ti4QS9sA8IXNW5lw7rsWx4de8prP1yrmF4MoMOXes+38pqyY5imiebEOSvsY5k Oxa1nnpedu0EnC2AJG17dnfdQnacerMGfcSHNoCqhDxYZ1T5tJIpLjMitSpf2Pf7mtYR zdcA== X-Gm-Message-State: APjAAAUnek7ywqh0kcOIL1el4Z0n5+0YBhCkHP3z6VGJlBuNnZWw4OPW fwFmlbCFbbYY7mJExiGQlpA= X-Google-Smtp-Source: APXvYqz/TCtGupy4vUlA4JJ7MZwaLggPXTzq3+N8NdvTZjo9d7iD5dlIU8MlPohOQZ7IpSI36es/hw== X-Received: by 2002:a1c:9d4c:: with SMTP id g73mr5419736wme.48.1553510548898; Mon, 25 Mar 2019 03:42:28 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:b00c:66c8:99df:336]) by smtp.gmail.com with ESMTPSA id n4sm24316043wrx.39.2019.03.25.03.42.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 03:42:27 -0700 (PDT) Message-ID: From: Luca Boccassi To: Ye Xiaolong Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" Date: Mon, 25 Mar 2019 10:42:26 +0000 In-Reply-To: <20190325024559.GB35864@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> 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 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: Mon, 25 Mar 2019 10:42:29 -0000 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 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 =3D elf_nextscn(elf, scn)) !=3D 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. --=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 8D6A2A05D3 for ; Mon, 25 Mar 2019 11:42:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4145D2BFA; Mon, 25 Mar 2019 11:42:30 +0100 (CET) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by dpdk.org (Postfix) with ESMTP id 5FD8A2BF4 for ; Mon, 25 Mar 2019 11:42:29 +0100 (CET) Received: by mail-wm1-f65.google.com with SMTP id o10so1207166wmc.1 for ; Mon, 25 Mar 2019 03:42:29 -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=ycixQRSd2abu2LtZzFh71gCG9vLFuMhs4+F4NQDRsNs=; b=rI6u45V5FpP2PIy+4pQYHG6mQu3mxLJ7ZK9NeetFmit/Hl4p0r/eb7x5M1Rv/ar+2S +UD4W3knY80X96KlUY/V6turIUGZg7Sg4TaotiE7FxmQJhTNm0B4iW63oAW3+fVkmY5N P9EHTpsB5PSihtsbGQlw449uZrTzeJHo95rel1d38YvxD8lQpnk54PHqIqVTaT+p8Yl5 ivp0q5Ti4QS9sA8IXNW5lw7rsWx4de8prP1yrmF4MoMOXes+38pqyY5imiebEOSvsY5k Oxa1nnpedu0EnC2AJG17dnfdQnacerMGfcSHNoCqhDxYZ1T5tJIpLjMitSpf2Pf7mtYR zdcA== X-Gm-Message-State: APjAAAUnek7ywqh0kcOIL1el4Z0n5+0YBhCkHP3z6VGJlBuNnZWw4OPW fwFmlbCFbbYY7mJExiGQlpA= X-Google-Smtp-Source: APXvYqz/TCtGupy4vUlA4JJ7MZwaLggPXTzq3+N8NdvTZjo9d7iD5dlIU8MlPohOQZ7IpSI36es/hw== X-Received: by 2002:a1c:9d4c:: with SMTP id g73mr5419736wme.48.1553510548898; Mon, 25 Mar 2019 03:42:28 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:b00c:66c8:99df:336]) by smtp.gmail.com with ESMTPSA id n4sm24316043wrx.39.2019.03.25.03.42.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Mar 2019 03:42:27 -0700 (PDT) Message-ID: From: Luca Boccassi To: Ye Xiaolong Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" Date: Mon, 25 Mar 2019 10:42:26 +0000 In-Reply-To: <20190325024559.GB35864@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> 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 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: <20190325104226.rLGlccX6pFOhlfYleq3VL3dFrdG0g6ae847TrbzK_Qo@z> 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 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 =3D elf_nextscn(elf, scn)) !=3D 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. --=20 Kind regards, Luca Boccassi