Bug 1912596
| Summary: | xdp-tools version update for RHEL 8.4 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Toke Høiland-Jørgensen <thoiland> |
| Component: | xdp-tools | Assignee: | Toke Høiland-Jørgensen <thoiland> |
| Status: | CLOSED ERRATA | QA Contact: | Zhiqian Guan <zhguan> |
| Severity: | unspecified | Docs Contact: | Sagar Dubewar <sdubewar> |
| Priority: | unspecified | ||
| Version: | 8.4 | CC: | echaudro, jbenc, jolsa, zhguan |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: |
.`xdp-tools` rebased to 1.1.0
The `xdp-tools` packages have been upgraded to upstream version 1.1.0, which provides a number of enhancements and bug fixes over the previous version:
* The `libxdp` library can now incrementally load multiple XDP programs on a single interface. Previously, multiple programs were supported only if they were attached at once.
* The `xdpdump` utility now supports dumping packets from individual sub-programs on an interface.
Loading and unloading programs in hardware offload mode on `Netronome` devices now works correctly.
* Adding and removing filter items behavior of the `xdp-filter` utility have been made consistent.
* You can now attach XDP programs in native mode by default instead of letting the kernel pick between native and generic mode.
* The `xdpdump` utility is now fully supported on the AMD and Intel 64-bit architectures. On other platforms, `xdpdump` is provided as an unsupported Technology Preview.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-18 16:09:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1924711 | ||
| Bug Blocks: | 1921557 | ||
|
Description
Toke Høiland-Jørgensen
2021-01-04 21:10:22 UTC
Updated dependency to specific backport instead of the whole 5.10 series... I thought I could just build the package now and push it with a test breaking until the kernel backports land, but of course we need the libbpf update to land first so we can link against it. So pushing this RPM will have to land until https://bugzilla.redhat.com/show_bug.cgi?id=1924711 makes it to and updated libbpf package in brew... (In reply to Toke Høiland-Jørgensen from comment #2) > I thought I could just build the package now and push it with a test > breaking until the kernel backports land, but of course we need the libbpf > update to land first so we can link against it. So pushing this RPM will > have to land until https://bugzilla.redhat.com/show_bug.cgi?id=1924711 makes > it to and updated libbpf package in brew... Jirka, could you please pull the libbpf changes from my latest rhkl submission into the libbpf package right away? (In reply to Jiri Benc from comment #3) > (In reply to Toke Høiland-Jørgensen from comment #2) > > I thought I could just build the package now and push it with a test > > breaking until the kernel backports land, but of course we need the libbpf > > update to land first so we can link against it. So pushing this RPM will > > have to land until https://bugzilla.redhat.com/show_bug.cgi?id=1924711 makes > > it to and updated libbpf package in brew... > > Jirka, could you please pull the libbpf changes from my latest rhkl > submission into the libbpf package right away? do you need just scratch build? I'd think for official build I should wait for changes to land in kernel (In reply to Jiri Olsa from comment #4) > I'd think for official build I should wait for changes to land in kernel The patches are acked, I don't think it's necessary. We need to make it in time for Beta, which means we have basically just Monday to sort this out. If we wait for the kernel patches to land in the non-devtest kernel before applying to the libbpf package, we'll miss Beta for sure. > do you need just scratch build? I'd think for official build > I should wait for changes to land in kernel No, I need it to be available as a dependency for builds in brew (both scratch and the "real" build). I have the xdp-tools RPM ready to go, but can't build it on the RH infrastructure because the dependency fails. Here's my failed scratch build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=34723979 ok, I made official build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=34781297 Right, awesome. Any idea how long that takes to be available for other builds in brew? Or even how to tell (other than trying a scratch build)? [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_1.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_2.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_3.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_4.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_5.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_6.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_7.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_8.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_9.o [root@netqe4 ~]# xdp-loader load ens3f0np0 xdp_prog_kern_10.o Couldn't attach XDP program on iface 'ens3f0np0': Argument list too long(-7) [root@netqe4 ~]# xdp-loader status CURRENT XDP PROGRAM STATUS: Interface Prio Program name Mode ID Tag Chain actions -------------------------------------------------------------------------------------- lo <No XDP program loaded!> eno1 <No XDP program loaded!> eno2 <No XDP program loaded!> ens3f0np0 xdp_dispatcher native 440 d51e469e988d81da => 50 xdp_pass_func 281 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 300 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 319 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 338 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 357 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 376 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 395 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 414 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 433 3b185187f1855c4c XDP_PASS => 50 xdp_pass_func 452 3b185187f1855c4c XDP_PASS eno3 <No XDP program loaded!> eno4 <No XDP program loaded!> ens3f1np1 <No XDP program loaded!> ens1f0 <No XDP program loaded!> ens1f1 <No XDP program loaded!> ens5 <No XDP program loaded!> ens5d1 <No XDP program loaded!> [root@netqe4 ~]# rpm -qa xdp-tools xdp-tools-1.1.1-2.el8.x86_64 [root@netqe4 ~]# uname -r 4.18.0-283.el8.dt3.x86_64 [root@netqe4 ~] We can incrementally load xdp programs, but when it comes to more than 10 programs, it seems it won't successfully load the program. maybe have a separate bz regard this issue. If this issue is confirmed, maybe we should have some docs to record this until we fix it? It's not supposed to - 10 is the maximum number of simultaneous programs supported by xdp-tools. We could increase this (it's just a compile-time constant), but I don't really see at need for that unless we actually run in to some real use case that needs more than 10 programs :) (In reply to Toke Høiland-Jørgensen from comment #15) > It's not supposed to - 10 is the maximum number of simultaneous programs > supported by xdp-tools. We could increase this (it's just a compile-time > constant), but I don't really see at need for that unless we actually run in > to some real use case that needs more than 10 programs :) OK, got it :) so in this case, should we have this 10 progs support documented in 8.4? or it's already documented somewhere Hmm, good question. No, I don't think we document this anywhere. I guess we should; I'll put it on the agenda for next week's XDP meeting, so we can discuss where to put this... https://beaker.engineering.redhat.com/jobs/5114724 - ice https://beaker.engineering.redhat.com/jobs/5114723 - cx5 https://beaker.engineering.redhat.com/jobs/5114721 - cx6 - fail https://beaker.engineering.redhat.com/jobs/5114720 - sfc https://beaker.engineering.redhat.com/jobs/5114719 - i40e https://beaker.engineering.redhat.com/jobs/5114718 - ixgbe Test on most of the cards pass, cx6 failed, will have more investigation, and have a separate bz if needed. Set this to Verified. cx6 fail caused by https://bugzilla.redhat.com/show_bug.cgi?id=1856795 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (xdp-tools bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2021:1925 |