From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Ciara Loftus <ciara.loftus@intel.com>, <dev@dpdk.org>
Subject: Re: [PATCH v3] net/af_xdp: use libxdp if available
Date: Tue, 1 Feb 2022 10:06:37 +0000 [thread overview]
Message-ID: <53216eae-d0d7-fa12-9feb-82d5649f8f6a@intel.com> (raw)
In-Reply-To: <Yfgk03X/YJW5NR0P@bricha3-MOBL.ger.corp.intel.com>
On 1/31/2022 6:05 PM, Bruce Richardson wrote:
> On Mon, Jan 31, 2022 at 05:59:53PM +0000, Ferruh Yigit wrote:
>> On 1/28/2022 9:50 AM, Ciara Loftus wrote:
>>> AF_XDP support is deprecated in libbpf since v0.7.0 [1]. The libxdp
>>> library now provides the functionality which once was in libbpf and
>>> which the AF_XDP PMD relies on. This commit updates the AF_XDP meson
>>> build to use the libxdp library if a version >= v1.2.2 is available. If
>>> it is not available, only versions of libbpf prior to v0.7.0 are
>>> allowed, as they still contain the required AF_XDP functionality.
>>>
>>> libbpf still remains a dependency even if libxdp is present, as we use
>>> libbpf APIs for program loading.
>>>
>>> The minimum required kernel version for libxdp for use with AF_XDP is
>>> v5.3. For the library to be fully-featured, a kernel v5.10 or newer is
>>> recommended. The full compatibility information can be found in the
>>> libxdp README.
>>>
>>> v1.2.2 of libxdp includes an important fix required for linking with
>>> DPDK which is why this version or greater is required. Meson uses
>>> pkg-config to verify the version of libxdp on the system, so it is
>>> necessary that the library is discoverable using pkg-config in order
>>> for the PMD to use it. To verify this, you can run: pkg-config
>>> --modversion libxdp
>>>
>>> [1] https://github.com/libbpf/libbpf/commit/277846bc6c15
>>>
>>> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
>>
>> Tested build with combination of following, build looks good libxdp
>> 1.2.0, libxdp 1.2.2 libbpf 0.7.0, libbpf 0.4.0
>>
>>
>> But while running testpmd can't find the libxdp.so by default [1],
>> although setting 'LD_LIBRARY_PATH' works
>> (LD_LIBRARY_PATH=/usr/local/lib64/ for my case), this wasn't required for
>> libbpf, just checking if this is expected?
>>
>> Similarly for 'build/drivers/librte_net_af_xdp.so', ldd can find 'libbpf'
>> but not libxdp.so (although they are in same folder): $ ldd
>> build/drivers/librte_net_af_xdp.so libxdp.so.1 => not found libbpf.so.0
>> => /usr/local/lib64/libbpf.so.0 (0x00007f2ceb86f000) ....
>>
>> Again, 'LD_LIBRARY_PATH' works: $ LD_LIBRARY_PATH=/usr/local/lib64/ ldd
>> build/drivers/librte_net_af_xdp.so libxdp.so.1 =>
>> /usr/local/lib64/libxdp.so.1 (0x00007fefa792e000) libbpf.so.0 =>
>> /usr/local/lib64/libbpf.so.0 (0x00007fefa78dc000)
>>
>>
>> But same question, why 'LD_LIBRARY_PATH' is not required for libbpf, but
>> required for libxdp, any idea?
>>
> Did you rerun "ldconfig" to refresh the ldd cache after installing the
> new library?
No I didn't.
But it works as expected next day without me doing anything, if the issue
was ldconfig there can be regular periodic runs for it (I expect installing
a new library automatically trigger the ldconfig).
Anyway, I am proceeding with patch as it is working now as expected.
next prev parent reply other threads:[~2022-02-01 10:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 10:58 [RFC PATCH] " Ciara Loftus
2022-01-12 13:07 ` [PATCH] " Ciara Loftus
2022-01-25 7:20 ` [PATCH v2] " Ciara Loftus
2022-01-25 9:27 ` Bruce Richardson
2022-01-27 8:42 ` Loftus, Ciara
2022-01-28 9:50 ` [PATCH v3] " Ciara Loftus
2022-01-31 17:59 ` Ferruh Yigit
2022-01-31 18:05 ` Bruce Richardson
2022-02-01 10:06 ` Ferruh Yigit [this message]
2022-02-01 10:11 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53216eae-d0d7-fa12-9feb-82d5649f8f6a@intel.com \
--to=ferruh.yigit@intel.com \
--cc=bruce.richardson@intel.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).