From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH v9 1/1] net/af_xdp: introduce AF XDP PMD driver Date: Wed, 3 Apr 2019 16:23:13 +0100 Message-ID: <20190403152313.GB1325@bricha3-MOBL.ger.corp.intel.com> References: <20190403095939.GA32340@intel.com> <56ce5855b02d47a085a8d36451561c400f0b039c.camel@debian.org> <0dde8c20e9992047f29d39ad45dcf511244a5297.camel@debian.org> <80c81c0c-cf64-59f8-a592-26cd865fbd89@intel.com> <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org> <5bc49c51-04f4-6f73-889d-d3c0ff749784@intel.com> <46d92b70a40581462f5ee3ba301c793c4cf0c2df.camel@debian.org> <20190403144327.GB36385@intel.com> <8f1ac08396f0deaca458201370c08b1334ee6b84.camel@debian.org> <20190403151458.GC36385@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Luca Boccassi , Ferruh Yigit , dev@dpdk.org To: Ye Xiaolong Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id E53921B49B for ; Wed, 3 Apr 2019 17:23:17 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20190403151458.GC36385@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Apr 03, 2019 at 11:14:58PM +0800, Ye Xiaolong wrote: > On 04/03, Luca Boccassi wrote: > >On Wed, 2019-04-03 at 22:43 +0800, Ye Xiaolong wrote: > >> On 04/03, Luca Boccassi wrote: > >> [snip] > >> > > Got it. > >> > > > >> > > In above steps, 'libbpf' also build from kernel source tree, will > >> > > it > >> > > be problem > >> > > in you builds to not have it build from source? > >> > > > >> > > If not, taking into account that xsk.h also will be fixed, only > >> > > 'tools/include/asm/barrier.h' remains the problem, and it looks > >> > > like > >> > > it can be > >> > > solved, please check above. > >> > > >> > libbpf is already packaged separately in Debian and I think other > >> > distros will follow soon, so it's all good for me once the barrier > >> > issue is solved. > >> > > >> > https://packages.debian.org/buster/libbpf-dev > >> > > >> > > >> > From the makefile's perspective it should not matter where it comes > >> > from - the headers should be expected to be in /usr/include and the > >> > library in /usr/lib* - and pkg-config can help with that if > >> > available. > >> > And if a user wants to use a custom path, then it's no different > >> > than > >> > any of the other dependencies on other external libraries > >> > >> From tools/lib/bpf/Makefile, after make install_lib and make > >> install_headers, > >> the headers and library would be put in /usr/local/include/bpf and > >> /usr/local/lib*, > >> Is it ok? > > > >Yes certainly that's fine, that's expected for local installations, and > >users can specify a prefix with the upstream's makefile if they want to > >install somewhere else. > > In my local test, if I run `make install_lib` to install the libbpf.so to > /usr/local/lib64, `-lbpf` specified in af_xdp pmd still fails to find the library, > the build would end up with a lot of undefined references which are defined in libbpf. > It means during dpdk compilation, it won't search libraries in /usr/local/lib*, right? > > Install the libbpf to /usr/lib64 via `make install_lib prefix=/usr` doesn't have > this issue, so shall I just document it in af_xdp.rst or there is other proper > way to do it? > At a guess I'd say you are using Fedora Linux, right? Fedora is unusual in that it doesn't by default add /usr/local to the library and header search paths so you need to explicitly add them to your environment. Other distros should work fine for this. /Bruce