[dpdk-dev] [PATCH v10 1/1] net/af_xdp: introduce AF XDP PMD driver

[Phil Yang (Arm Technology China)]

> -----Original Message-----
> From: dev <dev-bounces at dpdk.org> On Behalf Of Ye Xiaolong
> Sent: Thursday, April 4, 2019 1:55 PM
> To: Ferruh Yigit <ferruh.yigit at intel.com>; Luca Boccassi <bluca at debian.org>
> Cc: dev at dpdk.org; Stephen Hemminger <stephen at networkplumber.org>;
> Qi Zhang <qi.z.zhang at intel.com>; Karlsson Magnus
> <magnus.karlsson at intel.com>; Topel Bjorn <bjorn.topel at intel.com>;
> Maxime Coquelin <maxime.coquelin at redhat.com>; Bruce Richardson
> <bruce.richardson at intel.com>; Ananyev Konstantin
> <konstantin.ananyev at intel.com>; David Marchand
> <david.marchand at redhat.com>; Andrew Rybchenko
> <arybchenko at solarflare.com>; Olivier Matz <olivier.matz at 6wind.com>
> Subject: Re: [dpdk-dev] [PATCH v10 1/1] net/af_xdp: introduce AF XDP PMD
> driver
> 
> Hi, Luca
> 
> On 04/03, Luca Boccassi wrote:
> >On Wed, 2019-04-03 at 18:44 +0100, Ferruh Yigit wrote:
> >> On 4/3/2019 5:59 PM, Xiaolong Ye wrote:
> >> > Add a new PMD driver for AF_XDP which is a proposed faster version
> >> > of AF_PACKET interface in Linux. More info about AF_XDP, please
> >> > refer to [1] [2].
> >> >
> >> > This is the vanilla version PMD which just uses a raw buffer
> >> > registered as the umem.
> >> >
> >> > [1]
> >> > https://fosdem.org/2018/schedule/event/af_xdp/
> >> >
> >> > [2]
> >> > https://lwn.net/Articles/745934/
> >> >
> >> >
> >> > Signed-off-by: Xiaolong Ye <
> >> > xiaolong.ye at intel.com
> >> > >
> >>
> >> I am not able to test functionality but code looks good to me, I can
> >> compile via Makefile (with suggested steps in doc) but not able to
> >> build with meson, can you please check below comments?
> >>
> >> <...>
> >>
> >> > @@ -0,0 +1,21 @@
> >> > +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2019 Intel
> >> > +Corporation
> >> > +
> >> > +if host_machine.system() != 'linux'
> >> > +	build = false
> >> > +endif
> >>
> >> After this point, if build is false it shouldn't continue to below
> >> checks I think.
> >>
> >> > +
> >> > +bpf_dep = dependency('libbpf', required: false)
> >>
> >> My library is in '/usr/local/lib64/libbpf.so' but this line can't
> >> find it. Where does 'dependency()' checks for libraries?
> >
> >dependency() uses only pkg-config (or cmake or embedded specific tools,
> >neither of which applies to bpf), so if you haven't built from bpf-next
> >you won't have the pkg-config file installed, and it will fall back to
> >the next block.
> >
> >Side note, there's an issue open upstream in Meson to merge
> >dependency() and find_library(), with some traction but it's not done
> >yet.
> >
> >For me building from bpf-next it works fine:
> >
> >$ PKG_CONFIG_PATH=/tmp/bpf/lib64/pkgconfig/ ninja -C build-gcc-shared
> >...
> >Dependency libbpf found: YES 0.0.2
> >...
> >$ lddtree build-gcc-shared/drivers/librte_pmd_af_xdp.so.1.1
> >librte_pmd_af_xdp.so.1.1 => build-gcc-
> shared/drivers/librte_pmd_af_xdp.so.1.1 (interpreter => none)
> >    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> >    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> >    libnuma.so.1 => /lib/x86_64-linux-gnu/libnuma.so.1
> >    librte_ethdev.so.12 => build-gcc-
> shared/drivers/../lib/librte_ethdev.so.12
> >    librte_eal.so.10 => build-gcc-shared/drivers/../lib/librte_eal.so.10
> >    librte_kvargs.so.1 => build-gcc-shared/drivers/../lib/librte_kvargs.so.1
> >    librte_net.so.1 => build-gcc-shared/drivers/../lib/librte_net.so.1
> >    librte_mbuf.so.5 => build-gcc-shared/drivers/../lib/librte_mbuf.so.5
> >    librte_mempool.so.5 => build-gcc-
> shared/drivers/../lib/librte_mempool.so.5
> >    librte_ring.so.2 => build-gcc-shared/drivers/../lib/librte_ring.so.2
> >    librte_cmdline.so.2 => build-gcc-shared/drivers/../lib/librte_cmdline.so.2
> >    librte_meter.so.2 => build-gcc-shared/drivers/../lib/librte_meter.so.2
> >    librte_bus_pci.so.2 => not found
> >    librte_pci.so.1 => build-gcc-shared/drivers/../lib/librte_pci.so.1
> >    librte_bus_vdev.so.2 => not found
> >    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0
> >        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> >    libbpf.so.0 => /tmp/bpf/lib64/libbpf.so.0
> >        libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1
> >            libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
> >    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> >    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> >    ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
> >
> >> > +if bpf_dep.found()
> >> > +	build = true
> >> > +else
> >> > +	bpf_dep = cc.find_library('libbpf', required: false)
> >>
> >> Also this line can't find it, in log it says "(tried pkgconfig and
> >> cmake)" and yes there is no pkgconfig for it, any idea how 'cmake'
> >> used?
> >
> >The issue here is that it should be cc.find_library('bpf' - not
> >'libbpf'. I missed this when reviewing, good catch.
> >
> >That's because find_library just does a compilation test passing the
> >value to the compiler as a linker flag - so right now it's passing
> >-llibbpf. Fixing this line and the header line below makes it work
> >without pkg-config:
> >
> >$ CPPFLAGS=-I/tmp/bpf/include LDFLAGS=-L/tmp/bpf/lib64 meson testt ...
> >Dependency libbpf found: NO (tried pkgconfig and cmake) Library bpf
> >found: YES
> 
> After apply the fix in af_xdp pmd's meson.build, now I was able to build
> library for af_xdp pmd.
> 
> $ ls drivers/ |grep xdp
> a715181@@rte_pmd_af_xdp at sha
> a715181@@rte_pmd_af_xdp at sta
> a715181@@tmp_rte_pmd_af_xdp at sta
> librte_pmd_af_xdp.a
> librte_pmd_af_xdp.so
> librte_pmd_af_xdp.so.1
> librte_pmd_af_xdp.so.1.1
> libtmp_rte_pmd_af_xdp.a
> rte_pmd_af_xdp.pmd.c
> 
> But I found that if I install libbpf to /usr/local/lib64 by default, application built
> by meson build will fail to run:
> 
> $ ./dpdk-testpmd
> ./dpdk-testpmd: error while loading shared libraries: libbpf.so.0: cannot open
> shared object file: No such file or directory
> 
> While install libbpf to /usr/lib doesn't have this issue (I was testing on ubuntu
> system).
> Is it a expected behavior? Do we need any fix for it?

Hi, Xiaolong

I have encountered the same issue on ubuntu-arm64-server with Kernel v5.1.0-rc3+. 
If I read correctly, I think Luca's patch can solve this issue.
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=dd399ac9e343c7573c47d6820e4a23013c54749d 

So, will this patch in v5.1-rc4 ?

Thanks,
Phil

> 
> Thanks,
> Xiaolong
> >
> >> > +	if bpf_dep.found() and cc.has_header('xsk.h', dependencies:
> >> > bpf_dep) and cc.has_header('linux/if_xdp.h')
> >>
> >> Should this be 'lib/xsk.h' now?
> >
> >Yes, this should be 'bpf/xsk.h'
> >
> >--
> >Kind regards,
> >Luca Boccassi