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 D35E8A05D3 for ; Tue, 26 Mar 2019 11:14:28 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BA35B2BD3; Tue, 26 Mar 2019 11:14:27 +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 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) 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=QJUhqEK5rXwEskvirERZSTSmirAOIv/VBHX4Hw7c1xQ=; b=J4Rt8a2QK596mzRVCBQYBGp1M1iGDgEVqb5fnyKAO6wgxXYTVSiTobWjTkoaAMlxZA +5CrezYyQTghLVvuTT/TOarP97nQ3qmrKgIBEc46qhTKf6pihbY4R46AK02XCikIm4aX BSdgdcL0bpqeHBhuakY1Sqk05ZtaOa9iHeE2NCaVpc7mWHfx/edTKrpX9WfRUSlCMIlx l9xeUDlx00YnWWV+s3GgM7XF5DEK1vwIOk8I0lzs50xpdrBaQH6vj1F3HHYpUEGMqXmY 2FPK9vkyFNYjXFs2Xfr5zpcOFILYQErFsbcHR3/qcFau3YjNMTE365/g1VMe8dJzH+05 a9rw== X-Gm-Message-State: APjAAAWFzRz7VXR6olUJiVtWG2CnfSmok42C1Q+JYNRk6uTm1POxnalw DRAHUntzQLWbsQ6RXBi4/j0= X-Google-Smtp-Source: APXvYqyzPBaR1xieJLwwPNV+z83NagdDcwowIhQ/EoYf1l4nEUjkZuRpkq8z+i0W333fp2/WPJUV0g== X-Received: by 2002:a1c:eb14:: with SMTP id j20mr8970042wmh.32.1553595265924; Tue, 26 Mar 2019 03:14:25 -0700 (PDT) Received: from localhost ([2a01:4b00:f419:6f00:b00c:66c8:99df:336]) by smtp.gmail.com with ESMTPSA id o63sm20139556wmo.46.2019.03.26.03.14.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 26 Mar 2019 03:14:24 -0700 (PDT) Message-ID: <9b875fc3d5597cd8e793a8ac7b40a8b7efad6e74.camel@debian.org> From: Luca Boccassi To: Ye Xiaolong Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" Date: Tue, 26 Mar 2019 10:14:24 +0000 In-Reply-To: <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> <20190326021812.GB48057@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: <20190326101424.U3goGVqy_ve4oR9uBdR6638eUGjBO5srabUs27Mjph8@z> 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