From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <xiaolong.ye@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
by dpdk.org (Postfix) with ESMTP id 58B5A2C39
for <dev@dpdk.org>; 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 <xiaolong.ye@intel.com>
To: Luca Boccassi <bluca@debian.org>
Cc: dev@dpdk.org, Qi Zhang <qi.z.zhang@intel.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>
Message-ID: <20190326021812.GB48057@intel.com>
References: <20190301080947.91086-1-xiaolong.ye@intel.com>
<20190301080947.91086-2-xiaolong.ye@intel.com>
<e48b25c52b586c330fa035a8bc7cb3e05c848071.camel@debian.org>
<20190302081407.GD100586@intel.com>
<20190317033425.GA103486@intel.com>
<1553429237.20876.3.camel@debian.org>
<20190325024559.GB35864@intel.com>
<f1394d98ad092e40cb748a15b11e08070ddb747e.camel@debian.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f1394d98ad092e40cb748a15b11e08070ddb747e.camel@debian.org>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 7BDC9A05D3
for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <xiaolong.ye@intel.com>
To: Luca Boccassi <bluca@debian.org>
Cc: dev@dpdk.org, Qi Zhang <qi.z.zhang@intel.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>
Message-ID: <20190326021812.GB48057@intel.com>
References: <20190301080947.91086-1-xiaolong.ye@intel.com>
<20190301080947.91086-2-xiaolong.ye@intel.com>
<e48b25c52b586c330fa035a8bc7cb3e05c848071.camel@debian.org>
<20190302081407.GD100586@intel.com>
<20190317033425.GA103486@intel.com>
<1553429237.20876.3.camel@debian.org>
<20190325024559.GB35864@intel.com>
<f1394d98ad092e40cb748a15b11e08070ddb747e.camel@debian.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <f1394d98ad092e40cb748a15b11e08070ddb747e.camel@debian.org>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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