[dpdk-dev] [PATCH v1 1/6] net/af_xdp: introduce AF_XDP PMD driver

Luca Boccassi bluca at debian.org
Tue Mar 26 11:14:24 CET 2019


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)  +=
> > > > > > > > -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

Isn't the final version not out yet anyway till May? Can the fix be
included before the release?

-- 
Kind regards,
Luca Boccassi


More information about the dev mailing list