[Bug 1276] platform bus use after free
https://bugs.dpdk.org/show_bug.cgi?id=1276
David Marchand (david.march...@redhat.com) changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
CC||david.march...@redhat.com
Resolution|--- |FIXED
--- Comment #2 from David Marchand (david.march...@redhat.com) ---
Fixed in d780011158ea ("bus/platform: fix bus cleanup").
Thanks.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1133] missing #include in drivers/gpu/cuda/gdrcopy.c
https://bugs.dpdk.org/show_bug.cgi?id=1133
David Marchand (david.march...@redhat.com) changed:
What|Removed |Added
Resolution|--- |FIXED
CC||david.march...@redhat.com
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from David Marchand (david.march...@redhat.com) ---
Thanks for the report.
Fixed with: cda3d17609c2 ("gpu/cuda: fix build with external GDRCopy")
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1295] Virtio driver, packed mode, the first desc misses the next flag, causing the message to be sent abnormally
https://bugs.dpdk.org/show_bug.cgi?id=1295
Bug ID: 1295
Summary: Virtio driver, packed mode, the first desc misses the
next flag, causing the message to be sent abnormally
Product: DPDK
Version: 23.07
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: major
Priority: Normal
Component: vhost/virtio
Assignee: dev@dpdk.org
Reporter: fengjiang_...@163.com
Target Milestone: ---
In the virtio_xmit_pkts_packed sending interface, when the virio header and pkt
payload are added in two descs, the desc of the virtio-header is missing
VRING_DESC_F_NEXT flag, resulting in the virio header and pkt payload being
considered to be two pkts, resulting in an exception.
static inline void
virtqueue_enqueue_xmit_packed(struct virtnet_tx *txvq, struct rte_mbuf *cookie,
uint16_t needed, int use_indirect, int can_push,
int in_order)
{
struct virtio_tx_region *txr = txvq->hdr_mz->addr;
struct vq_desc_extra *dxp;
struct virtqueue *vq = virtnet_txq_to_vq(txvq);
struct vring_packed_desc *start_dp, *head_dp;
uint16_t idx, id, head_idx, head_flags;
int16_t head_size = vq->hw->vtnet_hdr_size;
struct virtio_net_hdr *hdr;
uint16_t prev;
bool prepend_header = false;
uint16_t seg_num = cookie->nb_segs;
id = in_order ? vq->vq_avail_idx : vq->vq_desc_head_idx;
dxp = &vq->vq_descx[id];
dxp->ndescs = needed;
dxp->cookie = cookie;
head_idx = vq->vq_avail_idx;
idx = head_idx;
prev = head_idx;
start_dp = vq->vq_packed.ring.desc;
head_dp = &vq->vq_packed.ring.desc[idx];
head_flags = cookie->next ? VRING_DESC_F_NEXT : 0;
>branch1： mbuf is not buffer-list, next == NULL, so No next flag
set
head_flags |= vq->vq_packed.cached_flags;
if (can_push) {
/* prepend cannot fail, checked by caller */
hdr = rte_pktmbuf_mtod_offset(cookie, struct virtio_net_hdr *,
-head_size);
prepend_header = true;
/* if offload disabled, it is not zeroed below, do it now */
if (!vq->hw->has_tx_offload)
virtqueue_clear_net_hdr(hdr);
} else if (use_indirect) {
/* setup tx ring slot to point to indirect
* descriptor list stored in reserved region.
*
* the first slot in indirect ring is already preset
* to point to the header in reserved region
*/
start_dp[idx].addr = txvq->hdr_mem +
RTE_PTR_DIFF(&txr[idx].tx_packed_indir, txr);
start_dp[idx].len = (seg_num + 1) * sizeof(struct
vring_packed_desc);
/* Packed descriptor id needs to be restored when inorder. */
if (in_order)
start_dp[idx].id = idx;
/* reset flags for indirect desc */
head_flags = VRING_DESC_F_INDIRECT;
head_flags |= vq->vq_packed.cached_flags;
hdr = (struct virtio_net_hdr *)&txr[idx].tx_hdr;
/* loop below will fill in rest of the indirect elements */
start_dp = txr[idx].tx_packed_indir;
idx = 1;
} else {
/* setup first tx ring slot to point to header
* stored in reserved region.
*/
start_dp[idx].addr = txvq->hdr_mem +
RTE_PTR_DIFF(&txr[idx].tx_hdr, txr);
start_dp[idx].len = vq->hw->vtnet_hdr_size;
hdr = (struct virtio_net_hdr *)&txr[idx].tx_hdr;
>branch2： Add virtio header desc, no next flag set
idx++;
if (idx >= vq->vq_nentries) {
idx -= vq->vq_nentries;
vq->vq_packed.cached_flags ^=
VRING_PACKED_DESC_F_AVAIL_USED;
}
}
if (vq->hw->has_tx_offload)
virtqueue_xmit_offload(hdr, cookie);
do {
uint16_t flags;
start_dp[idx].addr = VIRTIO_MBUF_DATA_DMA_ADDR(cookie, vq);
start_dp[idx].len = cookie->data_len;
if (prepend_header) {
start_dp[idx].addr -= head_size;
start_dp[idx].len += head_size;
prepend_header = false;
}
if (likely(idx != head_idx)) {
flags = cookie->next ? VRING_DESC_F_NEXT : 0;
flags |= vq->vq_packed.cached_flags;
start_dp[idx].flags = flags;
}
prev = idx;
idx++;
[Bug 1281] Build failure with Meson 1.2.1 on Windows
https://bugs.dpdk.org/show_bug.cgi?id=1281 Tyler Retzlaff (roret...@microsoft.com) changed: What|Removed |Added Resolution|--- |WONTFIX CC||roret...@microsoft.com Status|UNCONFIRMED |RESOLVED --- Comment #1 from Tyler Retzlaff (roret...@microsoft.com) --- Windows build of DPDK with meson versions other than 0.57 is not currently supported. As documented here: https://doc.dpdk.org/guides/windows_gsg/build_dpdk.html#install-the-build-system It would be nice to diagnose and work with the meson project to resolve the issues but I have insufficient time to prioritize the work. Please use meson 0.57 https://github.com/mesonbuild/meson/releases/tag/0.57.2 Thanks -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1281] Build failure with Meson 1.2.1 on Windows
https://bugs.dpdk.org/show_bug.cgi?id=1281 Thomas Monjalon (tho...@monjalon.net) changed: What|Removed |Added CC||tho...@monjalon.net Ever confirmed|0 |1 Resolution|WONTFIX |--- Status|RESOLVED|CONFIRMED --- Comment #2 from Thomas Monjalon (tho...@monjalon.net) --- We should not close a bug just because we don't find time to fix it. Reopening -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1296] net/mlx5 driver causing indirect pool leakage when testing IPv6 fragmentation
https://bugs.dpdk.org/show_bug.cgi?id=1296 Bug ID: 1296 Summary: net/mlx5 driver causing indirect pool leakage when testing IPv6 fragmentation Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: java@ericsson.com Target Milestone: --- When testing IPv6 fragmentation uisng net/mlx5 driver we noticed the indirect buffer is not returning to the pool and will eventually cause indirect pool to be exausted. when using intel nic with iavf driver with same application code the issue is not seen. There is also no issue for pcap driver. when review code https://github.com/DPDK/dpdk/blob/main/drivers/net/mlx5/mlx5_tx.h function mlx5_tx_free_mbuf(). Seems in rte_pktmbuf_prefree_seg(*pkts) the pkts->next will be set to NULL for indirect buffer which is linked to the direct buffer. Test is done by explicitly putting the indirect buffer back to mem pool at end of function mlx5_tx_free_mbuf(). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1273] eth_memif_rx segfault when burst size is greater than 32
https://bugs.dpdk.org/show_bug.cgi?id=1273
David Marchand (david.march...@redhat.com) changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED |RESOLVED
--- Comment #7 from David Marchand (david.march...@redhat.com) ---
Fixed in cd7b0da68287 ("net/memif: fix crash with large Rx burst").
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1297] iavf: vxlan tunnel inner tcp checksum offload result in inner ip checksum cleared to 0
https://bugs.dpdk.org/show_bug.cgi?id=1297 Bug ID: 1297 Summary: iavf: vxlan tunnel inner tcp checksum offload result in inner ip checksum cleared to 0 Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: dexia...@jaguarmicro.com Target Milestone: --- when using iavf test vxlan tunnel inner tcp checksum offload, tcp checksum offload result in inner ip checksum cleared to 0. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1298] memif disconnect thread vs. rx_burst worker thread(s) crash
https://bugs.dpdk.org/show_bug.cgi?id=1298
Bug ID: 1298
Summary: memif disconnect thread vs. rx_burst worker thread(s)
crash
Product: DPDK
Version: 21.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: bly...@gmail.com
Target Milestone: ---
Hello,
We have run into a timing issue between threads when using the memif interface
type and need some guidance.
Our application has a DPDK based process operating (among other things) a memif
server interface. The problem is exposed when this memif interface receives a
memif.disconnect message from the remote client, while in the middle of an
rte_eth_rx_burst() on this same memif interface. As the IRQ message handling is
on its own thread as compared to the DPDK worker thread doing the rx_burst,
this resulted in a crash. The backtraces for which have been shared below.
How does one ensure there are guard rails in place to gracefully exit the
rx-burst when a disconnect occurs? Or, how do we properly modify the code such
that we defer responding to the disconnect CB after the rx-burst operation has
completed?
We are utilizing DPDK 21.11.2. I have diff’d dpdks-stable:22.11.3 in
./drivers/net/memif, but I do not see anything obvious that would address this.
I did a similar diff for dpdk:23.07, but do not see anything obvious there
either.
-Mike
(gdb) thread 1
[Switching to thread 1 (Thread 0x7f17e2813600 (LWP 470))]
#0 0x7f17e374d225 in eth_memif_rx (queue=0x1189023b00,
bufs=0x7f17e28100e8, nb_pkts=32) at
../git/drivers/net/memif/rte_eth_memif.c:338
338 last_slot = __atomic_load_n(&ring->head,
__ATOMIC_ACQUIRE);
(gdb) bt
#0 0x7f17e374d225 in eth_memif_rx (queue=0x1189023b00,
bufs=0x7f17e28100e8, nb_pkts=32) at
../git/drivers/net/memif/rte_eth_memif.c:338
#1 0x0047e6fb in rte_eth_rx_burst (nb_pkts=32, rx_pkts=0x7f17e28100e8,
queue_id=0, port_id=) at /usr/include/rte_ethdev.h:5368
#2 pmd_main_loop () at ../git/swfw/api/src/swfwPmd.c:1086
#3 0x0047f309 in pmd_launch_one_lcore (dummy=) at
../git/my_process.c:1157
#4 0x7f17f7070e7c in eal_thread_loop (arg=) at
../git/lib/eal/linux/eal_thread.c:146
#5 0x7f17f4c3da72 in start_thread (arg=) at
pthread_create.c:442
#6 0x7f17f4cbf930 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) l
333 ring_size = 1 << mq->log2_ring_size;
334 mask = ring_size - 1;
335
336 if (type == MEMIF_RING_C2S) {
337 cur_slot = mq->last_head;
338 last_slot = __atomic_load_n(&ring->head,
__ATOMIC_ACQUIRE);
339 } else {
340 cur_slot = mq->last_tail;
341 last_slot = __atomic_load_n(&ring->tail,
__ATOMIC_ACQUIRE);
342 }
(gdb) p ring->head
Cannot access memory at address 0x7f17d8e58006
(gdb) thread 19
[Switching to thread 19 (Thread 0x7f17f0804600 (LWP 468))]
#0 0x7f17f4caf97b in __GI___close (fd=494) at
../sysdeps/unix/sysv/linux/close.c:27
27return SYSCALL_CANCEL (close, fd);
(gdb) bt
#0 0x7f17f4caf97b in __GI___close (fd=494) at
../sysdeps/unix/sysv/linux/close.c:27
#1 0x7f17e374f01f in memif_free_regions (dev=dev@entry=0x7f17f727f000
) at ../git/drivers/net/memif/rte_eth_memif.c:882
#2 0x7f17e37475d0 in memif_disconnect (dev=0x7f17f727f000
) at ../git/drivers/net/memif/memif_socket.c:623
#3 0x7f17f7091bd2 in eal_intr_process_interrupts (nfds=,
events=) at ../git/lib/eal/linux/eal_interrupts.c:1026
#4 eal_intr_handle_interrupts (totalfds=, pfd=20) at
../git/lib/eal/linux/eal_interrupts.c:1100
#5 eal_intr_thread_main (arg=) at
../git/lib/eal/linux/eal_interrupts.c:1172
#6 0x7f17f4c3da72 in start_thread (arg=) at
pthread_create.c:442
#7 0x7f17f4cbf930 in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1299] Split PST files with MailsDaddy
https://bugs.dpdk.org/show_bug.cgi?id=1299 Bug ID: 1299 Summary: Split PST files with MailsDaddy Product: DPDK Version: 21.11 Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: Normal Component: vhost/virtio Assignee: dev@dpdk.org Reporter: henrypi...@gmail.com Target Milestone: --- MailsDaddy is a software company that specializes in developing email migration and management tools such as IMAP Backup, PST Split, EML to PST Converter and more. Its software solutions are designed to make the process of transferring emails from one email client to another seamless and hassle-free. Which is very useful. PST Split tool to split large PST files effortlessly: MS Outlook is the most famous and widely used email client to manage emails but after some time of usage, it reaches its limits and creates many problems like lagging, slow performance and difficulty in managing. In that case, I suggest using the MailsDaddy PST Split tool. You will be amazed after using this tool as it is a standalone application and works with 100% security. The application provides several options for splitting large PST files such as split by date, split by size, split by folder, and split by email ID you can use any one according to your need. Read more: https://www.mailsdaddy.com/pst-split-tool/ Also visit: https://www.mailsdaddy.com/blogs/handle-break-large-pst-files-102030-gb/ Effortlessly export EML files with MailsDaddy EML to PST converter: MailsDaddy EML to PST converter tool is the most exclusive and appropriate solution for changing your EML data file into PST format. This standalone utility work without configuring and installing any other software. The application Easily change the EML data in various email file formats like PST, HTML, MHTML, RTF, and MSG without any error. It supports all Windows versions including Win 11, 10, 8.1, 8, 7, and previous. Get more info: https://www.mailsdaddy.com/eml-to-pst-converter/ PST merge tool to combine multiple PST files: MailsDaddy PST Merge and Join tool stands as the best solution for users seeking to merge multiple PST files into a single file without the risk of data loss. This application is developed with advanced algorithms that simplify the removal of duplicate emails with remarkable ease. Its user-friendly GUI interface makes it very easy for Outlook users to use it. You can easily operate this efficient software without any technical knowledge. For more info: https://www.mailsdaddy.com/pst-merge-and-join/ Backup IMAP emails effortlessly with MailsDaddy IMAP Backup tool: MailsDaddy IMAP Backup tool is one of the most used software for taking backups of IMAP emails into PST format. This application easily transfers the IMAP data in various email file formats like PST, MBOX, EML, Office 365, Mozilla Thunderbird, etc. I personally used this outstanding application many times. Any technical or non-technical users can easily use this tool to convert IMAP emails to PST format. To know more: https://www.mailsdaddy.com/imap-backup-tool/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1300] iavf: when ovs using tso，setting RTE_MBUF_F_TX_TCP_SEG and RTE_MBUF_F_TX_TCP_CKSUM meantime result in tso fail
https://bugs.dpdk.org/show_bug.cgi?id=1300 Bug ID: 1300 Summary: iavf: when ovs using tso，setting RTE_MBUF_F_TX_TCP_SEG and RTE_MBUF_F_TX_TCP_CKSUM meantime result in tso fail Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: Normal Component: eventdev Assignee: dev@dpdk.org Reporter: dexia...@jaguarmicro.com Target Milestone: --- when ovs using tso, setting RTE_MBUF_F_TX_TCP_SEG and RTE_MBUF_F_TX_TCP_CKSUM meantime result in tso fail. Please help to confirm that we can't set both at the same time? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1301] [dpdk-23.11] meson_tests/driver: core dumped occurred after link_bonding_autotest test
https://bugs.dpdk.org/show_bug.cgi?id=1301 Bug ID: 1301 Summary: [dpdk-23.11] meson_tests/driver: core dumped occurred after link_bonding_autotest test Product: DPDK Version: 23.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: songx.ji...@intel.com Target Milestone: --- [Environment] DPDK version: dpdk-23.11：77f913752a55c0262bfda99a1b69ca0bd804c6c7 Other software versions: name/version for QEMU, OVS, etc. Repeat as required. OS: Ubuntu 22.04.3 LTS/5.15.0-82-generic Compiler: gcc version 11.4.0 Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz NIC hardware: Intel Corporation Ethernet Controller E810-C for SFP [8086:1593] (rev 02) NIC firmware: driver: ice version: 5.15.0-82-generic firmware-version: 4.40 0x8001af8b 1.3444.0 [Test Setup] 1. compile dpdk rm -rf x86_64-native-linuxapp-gcc CC=gcc meson -Denable_kmods=False -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc ninja -C x86_64-native-linuxapp-gcc -j 72 2. blind port to vfio-pci ./usertools/dpdk-devbind.py -b vfio-pci 05:00.0 08:00.0 3. start test DPDK_TEST=link_bonding_autotest MALLOC_PERTURB_=94 /root/dpdk/x86_64-native-linuxapp-gcc/app/dpdk-test -c 0xff -a :05:00.0 -a :08:00.0 [Show the output from the previous commands.] + TestCase [62] : test_broadcast_verify_member_link_status_change_behaviour succeeded + TestCase [63] : test_reconfigure_bonding_device succeeded + TestCase [64] : test_close_bonding_device succeeded Invalid port_id=8 EAL: Test assert remove_members_and_stop_bonding_device line 658 failed: Failed to stop bonding port 8 + --- + + Test Suite Summary : Link Bonding Unit Test Suite + --- + + Tests Total : 65 + Tests Skipped : 0 + Tests Executed :65 + Tests Unsupported: 0 + Tests Passed : 65 + Tests Failed : 0 + --- + Test OK RTE>>Segmentation fault (core dumped) [Expected Result] no core dumped. + TestCase [62] : test_broadcast_verify_member_link_status_change_behaviour succeeded + TestCase [63] : test_reconfigure_bonding_device succeeded + TestCase [64] : test_close_bonding_device succeeded Invalid port_id=8 EAL: Test assert remove_members_and_stop_bonding_device line 658 failed: Failed to stop bonding port 8 + --- + + Test Suite Summary : Link Bonding Unit Test Suite + --- + + Tests Total : 65 + Tests Skipped : 0 + Tests Executed :65 + Tests Unsupported: 0 + Tests Passed : 65 + Tests Failed : 0 + --- + Test OK RTE>> [Regression] Is this issue a regression: (Y/N)Y commit 36c46e738120c381cf663c96692454c5aa75e203 Author: David Marchand Date: Wed Sep 27 13:45:15 2023 +0200 ethdev: cleanup shared data with the last port If no port is allocated and no port owner is still registered, ethdev from a primary process may release the memzone used to store port data. This makes it possible for the DPDK memory allocator to release associated resources back to the OS. Signed-off-by: David Marchand Acked-by: Morten Brørup lib/ethdev/ethdev_driver.c | 6 ++ lib/ethdev/ethdev_private.c | 21 - lib/ethdev/ethdev_private.h | 4 lib/ethdev/rte_ethdev.c | 3 +++ 4 files changed, 33 insertions, 1 deletion -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1299] Split PST files with MailsDaddy
https://bugs.dpdk.org/show_bug.cgi?id=1299 David Marchand (david.march...@redhat.com) changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||david.march...@redhat.com --- Comment #1 from David Marchand (david.march...@redhat.com) --- SPAM. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1302] dpdk-pcapdump regression
https://bugs.dpdk.org/show_bug.cgi?id=1302 Bug ID: 1302 Summary: dpdk-pcapdump regression Product: DPDK Version: 23.03 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: testpmd Assignee: dev@dpdk.org Reporter: nick.hedb...@gmail.com Target Milestone: --- Created attachment 262 --> https://bugs.dpdk.org/attachment.cgi?id=262&action=edit testpmd output for the two commits Commit 6026bfa breaks dumpcap on CX6 DX, the previous commit. 742be6a, didn't show this issue. The error with this commit is: > ~/dpdk/build-6026bfa$ sudo ./app/dpdk-testpmd -c 0xf0 -n 4 -a :03:00.0 -- > -i --port-topology=chained ... > testpmd> start > Packet forwarding already started > testpmd> pdump_register_rx_callbacks(): rx callback for port=0 queue=0, > already exists and: >~/dpdk/build-6026bfa$ sudo ./app/dpdk-dumpcap -i 0 -c 6 -i 0 -w >/tmp/sample.pcapng File: /tmp/sample.pcapng >pdump_prepare_client_request(): client request for pdump enable/disable failed >EAL: Error - exiting with code: 1 > Cause: Packet dump enable on 0::03:00.0 failed Operation not permitted -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1303] [DPDK-23.11] hotplug_mp/attach_detach_dev_primary_cross_loop: re-attach device failed in multiple processes
https://bugs.dpdk.org/show_bug.cgi?id=1303 Bug ID: 1303 Summary: [DPDK-23.11] hotplug_mp/attach_detach_dev_primary_cross_loop: re-attach device failed in multiple processes Product: DPDK Version: 23.11 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: tingtingx.l...@intel.com Target Milestone: --- Environment DPDK version: 77f913752a55c0262bfda99a1b69ca0bd804c6c7 OS: Ubuntu 22.04.3 LTS/5.15.0-82-generic Compiler: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 NIC hardware: Ethernet Controller E810-C for SFP 1593 Hardware platform: Intel(R) Xeon(R) Gold 6139 CPU @ 2.30GHz NIC driver: ice-1.13.0_rc90_2_g5c64af920_dirty NIC firmware: 4.40 0x8001afdb 1.3444.0 Test Setup 1. compile hotplug_mp. meson configure -Dexamples=multi_process/hotplug_mp x86_64-native-linuxapp-gcc ninja -C x86_64-native-linuxapp-gcc 2. bind all PF to ice and start 3 processes ./usertools/dpdk-devbind.py -b ice :18:00.0 PRIMARY process: x86_64-native-linuxapp-gcc/examples/dpdk-hotplug_mp --proc-type=auto SECONDARY process-1: x86_64-native-linuxapp-gcc/examples/dpdk-hotplug_mp --proc-type=auto SECONDARY process-2: x86_64-native-linuxapp-gcc/examples/dpdk-hotplug_mp --proc-type=auto 3. bind all PF to vfio-pci ./usertools/dpdk-devbind.py -b vfio-pci :18:00.0 4. attach device in PRIMARY process attach :18:00.0 5. detach device in SECONDARY process-1 detach :18:00.0 6. re-attach device in PRIMARY process attach :18:00.0 [Output] EAL: Using IOMMU type 1 (Type 1) EAL: Probe PCI driver: net_ice (8086:1593) device: :18:00.0 (socket 1) ice_load_pkg_type(): Active package is: 1.3.36.0, ICE OS Default Package (double VLAN mode) EAL: Failed to attach device on secondary process EAL: Releasing PCI mapped resource for :18:00.0 EAL: Calling pci_unmap_resource for :18:00.0 at 0x220201 EAL: Calling pci_unmap_resource for :18:00.0 at 0x220401 failed to attached device :18:00.0 Expected Result Explain what is the expected result in text or as an example output: [Expected Result] EAL: Using IOMMU type 1 (Type 1) EAL: Probe PCI driver: net_ice (8086:1593) device: :18:00.0 (socket 1) ice_load_pkg_type(): Active package is: 1.3.36.0, ICE OS Default Package (double VLAN mode) attached device :18:00.0 Regression Is this issue a regression: (Y/N)Y commit 36c46e738120c381cf663c96692454c5aa75e203 Author: David Marchand Date: Wed Sep 27 13:45:15 2023 +0200 ethdev: cleanup shared data with the last port If no port is allocated and no port owner is still registered, ethdev from a primary process may release the memzone used to store port data. This makes it possible for the DPDK memory allocator to release associated resources back to the OS. Signed-off-by: David Marchand Acked-by: Morten Brørup -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1270] drivers/dma/skeleton/ is not setting pthread affinity based on the lcore shared as arguments
https://bugs.dpdk.org/show_bug.cgi?id=1270
David Marchand (david.march...@redhat.com) changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||david.march...@redhat.com
Resolution|--- |FIXED
--- Comment #4 from David Marchand (david.march...@redhat.com) ---
Fixed in commit 2f9afbe4f6fc ("dma/skeleton: fix thread affinity").
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1304] l3fwd-power example fails to run with uncore options, -U -u and -i
https://bugs.dpdk.org/show_bug.cgi?id=1304
Bug ID: 1304
Summary: l3fwd-power example fails to run with uncore options,
-U -u and -i
Product: DPDK
Version: 23.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: karen.ke...@intel.com
Target Milestone: ---
We suspect this particular commit introduces this bug, the sample app will not
work with the -U -u and -i options.
The options worked when I tried with 23.07. I also tried removing this commit
and the options worked again.
Result of git show:
commit ac1edcb6621af6ff3c2b01d40e4dd6ed0527a748
Author: Sivaprasad Tummala
Date: Wed Aug 16 03:09:57 2023 -0700
power: refactor uncore power management API
Currently the uncore power management implementation is vendor specific.
Added new vendor agnostic uncore power interface similar to rte_power
and rename specific implementations ("rte_power_intel_uncore") to
"power_intel_uncore" along with functions.
Signed-off-by: Sivaprasad Tummala
DPDK Version: 23.11-rc1
Commands:
.//examples/dpdk-l3fwd-power -c 0x6 -n 1 -- -p 0x1 -P
--config="(0,0,2)" -U
.//examples/dpdk-l3fwd-power -c 0x6 -n 1 -- -p 0x1 -P
--config="(0,0,2)" -u
.//examples/dpdk-l3fwd-power -c 0x6 -n 1 -- -p 0x1 -P
--config="(0,0,2)" -i 2
Error:
EAL: Error - exiting with code: 1
Cause: Invalid L3FWD parameters
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1305] testpmd: early exit with tap driver in non interactive mode
https://bugs.dpdk.org/show_bug.cgi?id=1305
Bug ID: 1305
Summary: testpmd: early exit with tap driver in non interactive
mode
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: david.march...@redhat.com
Target Milestone: ---
Reported by Frode, while running OVS-DPDK unit tests.
testpmd behavior changed with commit 0fd1386c30c3 ("app/testpmd: cleanup
cleanly from signal"). Any signal makes testpmd quit.
This can be problematic with the tap driver which uses internal signalling.
Reproducer with strace to illustrate the issue:
$ sudo strace -f -e trace=file build-clang/app/dpdk-testpmd -c 3 --no-huge -m
40 -a 0:0.0 --vdev net_tap0 -- --no-mlockall --total-num-mbufs=2048 -a
...
No commandline core given, start packet forwarding
io packet forwarding - ports=1 - cores=1 - streams=1 - NUMA support enabled, MP
allocation mode: native
Logical Core 1 (socket 0) forwards packets on 1 streams:
RX P=0/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00
[pid 3780703] --- SIGRT_3 {si_signo=SIGRT_3, si_code=0x1, si_pid=65, si_uid=0,
si_int=22, si_ptr=0x16} ---
io packet forwarding packets/burst=32
nb forwarding cores=1 - nb forwarding ports=1
port 0: RX queue number: 1 Tx queue number: 1
Rx offloads=0x0 Tx offloads=0x0
RX queue: 0
RX desc=0 - RX free threshold=0
RX threshold registers: pthresh=0 hthresh=0 wthresh=0
RX Offloads=0x0
TX queue: 0
TX desc=0 - TX free threshold=0
TX threshold registers: pthresh=0 hthresh=0 wthresh=0
TX offloads=0x0 - TX RS bit threshold=0
Press enter to exit
[pid 3780703] --- SIGRT_3 {si_signo=SIGRT_3, si_code=0x1, si_pid=65, si_uid=0,
si_int=22, si_ptr=0x16} ---
Telling cores to stop...
Waiting for lcores to finish...
-- Forward statistics for port 0 --
RX-packets: 1 RX-dropped: 0 RX-total: 1
TX-packets: 1 TX-dropped: 0 TX-total: 1
+++ Accumulated forward statistics for all ports+++
RX-packets: 1 RX-dropped: 0 RX-total: 1
TX-packets: 1 TX-dropped: 0 TX-total: 1
Done.
Stopping port 0...
Stopping ports...
Done
Shutting down port 0...
Closing ports...
Port 0 is closed
Done
Bye...
[pid 3780705] --- SIGRTMIN {si_signo=SIGRTMIN, si_code=SI_TKILL,
si_pid=3780703, si_uid=0} ---
[pid 3780705] +++ exited with 0 +++
[pid 3780703] unlink("/var/run/dpdk/rte/mp_socket") = 0
[pid 3780703] unlink("/var/run/dpdk/rte/dpdk_telemetry.v2:1") = 0
==3780703==LeakSanitizer has encountered a fatal error.
==3780703==HINT: For debugging, try setting environment variable
LSAN_OPTIONS=verbosity=1:log_threads=1
==3780703==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
[pid 3780710] +++ exited with 1 +++
[pid 3780704] +++ exited with 1 +++
[pid 3780706] +++ exited with 1 +++
+++ exited with 1 +++
A quick fix I tried:
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 595b77748c..57d257623e 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -4743,22 +4743,11 @@ main(int argc, char** argv)
}
} else {
char c;
- fd_set fds;
printf("Press enter to exit\n");
- FD_ZERO(&fds);
- FD_SET(0, &fds);
-
- /* wait for signal or enter */
- ret = select(1, &fds, NULL, NULL, NULL);
- if (ret < 0 && errno != EINTR)
- rte_exit(EXIT_FAILURE,
-"Select failed: %s\n",
-strerror(errno));
-
/* if got enter then consume it */
- if (ret == 1 && read(0, &c, 1) < 0)
+ if (read(0, &c, 1) < 0 && errno != EINTR)
rte_exit(EXIT_FAILURE,
"Read failed: %s\n",
strerror(errno));
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1306] hash: internal hash key pointer overflow
https://bugs.dpdk.org/show_bug.cgi?id=1306
Bug ID: 1306
Summary: hash: internal hash key pointer overflow
Product: DPDK
Version: 23.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: sz@navercorp.com
Target Milestone: ---
Hello,
I discovered that an overflow occurred in an internal variable used in the hash
library.
If the value of [slot_id * h->key_entry_size] is more than 32 bits,
the pointer of [new_k] will be entered with the wrong value.
Therefore, type casting to uint64_t is required for the calculation result.
- free_slots = 1 to total entries
- slot_id = total entries or less
- key_entry_size = sizeof(rte_hash_key) + sizeof(user key)
The above three variables are the internal values of the DPDK HASH.
The free_slots is a ring structure, filled with 1 to total entries.
The values of free_slots is used by slot_id.
And the key_entry_size becomes the size of the key value set by the user.
The following example shows a situation where the issue occurs.
Example)
- global variable :
entries = 2^28
key_entry_size = 32
- no issue case :
2^26(slot_id) * 32(key_entry_size) = 0x8000 (32bit)
- issue case :
2^27(slot_id) * 32(key_entry_size) = 0x1 (33bit)
2^28(slot_id) * 32(key_entry_size) = 0x2 (34bit)
I think it should be changed as follows diff code. Is that correct?
Signed-off-by: SeongJoong Kim
---
lib/hash/rte_cuckoo_hash.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c
index d92a903bb3..10ffa500d2 100644
--- a/lib/hash/rte_cuckoo_hash.c
+++ b/lib/hash/rte_cuckoo_hash.c
@@ -636,7 +636,7 @@ rte_hash_reset(struct rte_hash *h)
}
memset(h->buckets, 0, h->num_buckets * sizeof(struct rte_hash_bucket));
-memset(h->key_store, 0, h->key_entry_size * (h->entries + 1));
+memset(h->key_store, 0, (uint64_t) h->key_entry_size * (h->entries + 1));
*h->tbl_chng_cnt = 0;
/* reset the free ring */
@@ -705,7 +705,7 @@ search_and_update(const struct rte_hash *h, void *data,
const void *key,
for (i = 0; i < RTE_HASH_BUCKET_ENTRIES; i++) {
if (bkt->sig_current[i] == sig) {
k = (struct rte_hash_key *) ((char *)keys +
-bkt->key_idx[i] * h->key_entry_size);
+(uint64_t) bkt->key_idx[i] * h->key_entry_size);
if (rte_hash_cmp_eq(key, k->key, h) == 0) {
/* The store to application data at *data
* should not leak after the store to pdata
@@ -1071,7 +1071,7 @@ __rte_hash_add_key_with_hash(const struct rte_hash *h,
const void *key,
return -ENOSPC;
}
-new_k = RTE_PTR_ADD(keys, slot_id * h->key_entry_size);
+new_k = RTE_PTR_ADD(keys, (uint64_t) slot_id * h->key_entry_size);
/* The store to application data (by the application) at *data should
* not leak after the store of pdata in the key store. i.e. pdata is
* the guard variable. Release the application data to the readers.
@@ -1256,7 +1256,7 @@ search_one_bucket_l(const struct rte_hash *h, const void
*key,
if (bkt->sig_current[i] == sig &&
bkt->key_idx[i] != EMPTY_SLOT) {
k = (struct rte_hash_key *) ((char *)keys +
-bkt->key_idx[i] * h->key_entry_size);
+(uint64_t) bkt->key_idx[i] * h->key_entry_size);
if (rte_hash_cmp_eq(key, k->key, h) == 0) {
if (data != NULL)
@@ -1294,7 +1294,7 @@ search_one_bucket_lf(const struct rte_hash *h, const void
*key, uint16_t sig,
__ATOMIC_ACQUIRE);
if (key_idx != EMPTY_SLOT) {
k = (struct rte_hash_key *) ((char *)keys +
-key_idx * h->key_entry_size);
+(uint64_t) key_idx * h->key_entry_size);
if (rte_hash_cmp_eq(key, k->key, h) == 0) {
if (data != NULL) {
@@ -1492,7 +1492,7 @@ __hash_rcu_qsbr_free_resource(void *p, void *e, unsigned
int n)
keys = h->key_store;
k = (struct rte_hash_key *) ((char *)keys +
-rcu_dq_entry.key_idx * h->key_entry_size);
+(uint64_t) rcu_dq_entry.key_idx * h->key_entry_size);
key_data = k->pdata;
if (h->hash_rcu_cfg->free_key_data_func)
h->hash_rcu_cfg->free_key_data_func(h->hash_rcu_cfg->key_data_ptr,
@@ -1654,7 +1654,7 @@ search_and_remove(const struct rte_hash *h, const void
*key,
__ATOMIC_ACQUIRE);
if (bkt->sig_current[i] == sig && key_idx != EMPTY_SLOT) {
k = (struct rte_hash_key *) ((char *)keys +
-key_idx * h->key_entry_size);
+(uint64_t) key_idx * h->key_entry_size);
if (rte_hash_cmp_eq(key, k->k
[Bug 1076] [dpdk 22.11] kernel/linux/kni meson build failed with gcc 11.3.1 on rhel9.0
https://bugs.dpdk.org/show_bug.cgi?id=1076
Ferruh YIGIT (ferr...@gmail.com) changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID |---
CC||ferr...@gmail.com
Status|RESOLVED|CONFIRMED
--- Comment #2 from Ferruh YIGIT (ferr...@gmail.com) ---
Hi Daxue,
The problem is neither related to the compiler version nor the commit listed
above, it should be related to the kernel version.
The related build error fixed in commit:
c98600d4bed6 ("kni: fix build with Linux 5.18")
Starting with kernel version 5.18, 'netif_rx_ni()' function is removed from
kernel.
Having a build error with RHEL9.0/5.14.0-160.el9.x86_64 kernel means it
backported related kernel commit.
So, I expect the issue is still valid and it needs a special RHEL version check
in KNI.
Can you please double check with RHEL9 again?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1105] [dpdk-22.11] unit_tests_loopback: pmd_perf_autotest failed
https://bugs.dpdk.org/show_bug.cgi?id=1105 Bug ID: 1105 Summary: [dpdk-22.11] unit_tests_loopback: pmd_perf_autotest failed Product: DPDK Version: 22.11 Hardware: All OS: FreeBSD Status: UNCONFIRMED Severity: normal Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: linglix.c...@intel.com Target Milestone: --- Environment OS: FreeBSD 13.1-RELEASE Test Setup 1. build dpdk CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=static x86_64-native-bsdapp-gcc ninja -C x86_64-native-bsdapp-gcc 2.kldload ./x86_64-native-bsdapp-gcc/kernel/freebsd/contigmem.ko kldload ./x86_64-native-bsdapp-gcc/kernel/freebsd/nic_uio.ko 3. launch testpmd x86_64-native-bsdapp-gcc/app/test/dpdk-test -l 2-39 -n 4 -a 84:00.0 -a 84:00.1 4.start autotest RTE>>pmd_perf_autotest Show the output from the previous commands Start PMD RXTX cycles cost test. Allocated mbuf pool on socket 0 CONFIG RXD=1024 TXD=1024 No avail lcore to run test Test Failed Expected Result Test OK Regression Is this issue a regression: (Y/N)Y Version the regression was introduced: Specify git id if known. commit 7dcd73e37965ba0bfa430efeac362fe183ed0ae2 Author: Olivier Matz Date: Tue Oct 4 16:58:50 2022 +0200 drivers/bus: set device NUMA node to unknown by default The dev->device.numa_node field is set by each bus driver for every device it manages to indicate on which NUMA node this device lies. When this information is unknown, the assigned value is not consistent across the bus drivers. Set the default value to SOCKET_ID_ANY (-1) by all bus drivers when the NUMA information is unavailable. This change impacts rte_eth_dev_socket_id() in the same manner. Signed-off-by: Olivier Matz -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1106] ipsec-secgw inline test fail
https://bugs.dpdk.org/show_bug.cgi?id=1106
Bug ID: 1106
Summary: ipsec-secgw inline test fail
Product: DPDK
Version: 22.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: examples
Assignee: dev@dpdk.org
Reporter: vladimir.medved...@intel.com
Target Milestone: ---
To reproduce:
NIC used with test:
Network devices using DPDK-compatible driver
:af:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb' drv=vfio-pci
unused=ixgbe
running command:
./examples/ipsec-secgw/test/run_test.sh -4i
starting inline test trs_aesgcm
Test environment configuration:
[enabled] library mode
[disabled] extended sequence number
[disabled] sequence number atomic behavior
[enabled] inline crypto mode
[disabled] crypto fallback mode
[disabled] multi-segment test
...
ERROR: ./examples/ipsec-secgw/test/linux_test.sh failed for dst=192.168.31.14,
sz=1
inline test IPv4 trs_aesgcm finished with status 1
ERROR inline test trs_aesgcm FAILED
First bad commit:
commit 4edcee19fc20be7c28da3e06e3be5e8567162f01
Author: Nithin Dabilpuram
Date: Thu Jul 21 21:01:31 2022 +0530
examples/ipsec-secgw: use Tx checksum offload conditionally
Use Tx checksum offload only when all the ports have it enabled as
the qconf for a particular lcore stores ipv4_offloads for all the
Tx ports and each lcore can Tx to any port.
Fixes: 03128be4cd4d ("examples/ipsec-secgw: allow disabling some Rx/Tx
offloads")
Cc: sta...@dpdk.org
Signed-off-by: Nithin Dabilpuram
Acked-by: Akhil Goyal
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1107] [22.11-rc1][meson test] seqlock_autotest test failed
https://bugs.dpdk.org/show_bug.cgi?id=1107 Bug ID: 1107 Summary: [22.11-rc1][meson test] seqlock_autotest test failed Product: DPDK Version: 22.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: yux.ji...@intel.com Target Milestone: --- [Environment] DPDK version: dpdk22.11.0rc1 a74b1b25136a592c275afbfa6b70771469750aee OS: CentOS7.9/3.10.0-1160.62.1.el7.x86_64 or 3.10.0-1160.71.1.el7.x86_64 Compiler: gcc version 4.8.5 20150623 Hardware platform: Intel(R) Atom(TM) CPU C3758 @ 2.20GHz [Test Setup] Steps to reproduce 1. Use the following command to build DPDK: CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=static x86_64-native-linuxapp-gcc/ ninja -C x86_64-native-linuxapp-gcc/ 2. Execute the following command in the dpdk directory. meson test -C x86_64-native-bsdapp-gcc/ seqlock_autotest [Show the output from the previous commands] 2/2 DPDK:fast-tests / seqlock_autotest FAIL 2.51s (exit status 255 or signal 127 SIGinvalid) 04:23:38 MALLOC_PERTURB_=139 DPDK_TEST=seqlock_autotest /root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test --file-prefix=seqlock_autotest --- output --- stdout: RTE>>seqlock_autotest^M Reader observed inconsistent data values 10856068477537484964 9973142773974991064 9973142773974991064 Test Failed RTE>> stderr: EAL: Detected CPU lcores: 8 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/seqlock_autotest/mp_socket EAL: Selected IOVA mode 'VA' EAL: 1024 hugepages of size 2097152 reserved, but no mounted hugetlbfs found for that size APP: HPET is not enabled, using TSC as default timer [Expected Result] Test ok. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1108] i40e completely ignores flow rule transfer attribute prio to 22.11-rc1
https://bugs.dpdk.org/show_bug.cgi?id=1108 Bug ID: 1108 Summary: i40e completely ignores flow rule transfer attribute prio to 22.11-rc1 Product: DPDK Version: 22.07 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: andrew.rybche...@oktetlabs.ru Target Milestone: --- i40e completely ignores flow rule transfer attribute prio to 22.11-rc1 It is bad to ignore since transfer rule will be incorrectly treated as non-transfer. In fact it ignores it after 22.11-rc1 as well, but since ingress is prohibited with transfer in 22.11-rc1 flow rule insertion fails anyway because of missing ingress attribute set which is required in ice flow rules. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1109] ice completely ignores flow rule transfer attribute prio to 22.11-rc1
https://bugs.dpdk.org/show_bug.cgi?id=1109 Bug ID: 1109 Summary: ice completely ignores flow rule transfer attribute prio to 22.11-rc1 Product: DPDK Version: 22.07 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: andrew.rybche...@oktetlabs.ru Target Milestone: --- ice completely ignores flow rule transfer attribute prio to 22.11-rc1 It is bad to ignore since transfer rule will be incorrectly treated as non-transfer. In fact it ignores it after 22.11-rc1 as well, but since ingress is prohibited with transfer in 22.11-rc1 flow rule insertion fails anyway because of missing ingress attribute set which is required in ice flow rules. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1106] ipsec-secgw inline test fail
https://bugs.dpdk.org/show_bug.cgi?id=1106 Vladimir (vladimir.medved...@intel.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vladimir (vladimir.medved...@intel.com) --- This patch fixes the problem: https://patches.dpdk.org/project/dpdk/patch/20220930124055.2682935-1-radu.nico...@intel.com/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1110] i40e: runtime Rx/Tx queue setup is unusable
https://bugs.dpdk.org/show_bug.cgi?id=1110 Bug ID: 1110 Summary: i40e: runtime Rx/Tx queue setup is unusable Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: ivan.ma...@oktetlabs.ru Target Milestone: --- Created attachment 225 --> https://bugs.dpdk.org/attachment.cgi?id=225&action=edit probable-fix Results that have been collected by an ethdev testing tool, [1], which is opensource, suggest that i40e PMD might have a bug in runtime queue setup. According to log [2], if a Tx queue has not been set up, starting the device will fail. Apparently, the driver does not take the runtime setup feature into account when queues are started in a loop. The proposed fix shows the gist of the problem. The said bug also manifests itself with regard to Rx queues. [1] http://mails.dpdk.org/archives/dev/2022-October/251663.html [2] https://ts-factory.io/bublik/v2/log/123183?focusId=123948&mode=treeAndlog -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1111] i40e: buffer size fields may overflow in Rx descriptors
https://bugs.dpdk.org/show_bug.cgi?id= Bug ID: Summary: i40e: buffer size fields may overflow in Rx descriptors Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: ivan.ma...@oktetlabs.ru Target Milestone: --- Created attachment 226 --> https://bugs.dpdk.org/attachment.cgi?id=226&action=edit probable-fix It appears that opensource ethdev tests [1] have detected a bug in i40e PMD: by the looks of it, Rx descriptor fill-out is not robust against overflow in data buffer size field, which happens when the user provides a mempool with excessively large objects on Rx setup. A test log example can be found at [2]. In it, a mempool with mbuf data size of 32900 B is used. The test sends one packet to the NIC, but the PMD sees 5 packets which have no payload. Manual debugging indicates that, in the driver, round-up gives the value of 32768 B, which then gives the value of 256 to use in 7-bit "dbuff" field of an Rx descriptor ([3]). The value overflows, hence the test result. A probable fix is attached to the ticket. [1] http://mails.dpdk.org/archives/dev/2022-October/251663.html [2] https://ts-factory.io/bublik/v2/log/123183?focusId=123879&mode=treeAndlog [3] https://github.com/DPDK/dpdk/blob/main/drivers/net/i40e/base/i40e_lan_hmc.c#L709 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1112] MLX5: Not able to configure flows on PPPoE, stacked vlan tunnels & enable multiple tunnels at a time
https://bugs.dpdk.org/show_bug.cgi?id=1112 Bug ID: 1112 Summary: MLX5: Not able to configure flows on PPPoE, stacked vlan tunnels & enable multiple tunnels at a time Product: DPDK Version: 22.03 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: cagnibu...@vusra.com Target Milestone: --- Hello Team, We need to distribute packets on Inner-Hash5Tuple (IP-IP-Port-Port-Protocol) on Rx queues of below mentioned packet hierarchies. we're using rte_flow to create rules on group 0 with action RSS. Packet hierarchy: Case 1: ETH->VLAN1_QinQ->VLAN2_QinQ->VLAN3_QinQ->VLAN4_QinQ->PPPoE->PPP->IPv4/v6->TCP/UDP. We tried following: 1. If we configure flow rte_flow_item pattern as ETH->VLAN->VLAN, API throws error for multiple VLANs 2. If we configure ETH->ANY->PPPoES->.., API throws "item not supported" Please suggest way to support the hierarchy. Secondly, we want to enable GTP, IPinIP & other tunnels at same time, to enable GTP, mlx5 has configure to FLEX_PARSER_PROFILE_ENABLE=3 & to other value to support another. Card Model: Connectx-6 Dx OS: Ubuntu 20.04 Firmware: 22.32.2004 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1103] [dpdk-next-crypto] examples/fips_validation meson build failed on centos7.9 with gcc4.8
https://bugs.dpdk.org/show_bug.cgi?id=1103 gaodaxue (daxuex@intel.com) changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from gaodaxue (daxuex@intel.com) --- Verified based on e205fbb145 PASSED. centos7.9/3.10.0-1160.el7.x86_64 GCC Version: gcc 4.8.5 20150623 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1105] [dpdk-22.11] unit_tests_loopback: pmd_perf_autotest failed
https://bugs.dpdk.org/show_bug.cgi?id=1105 David Marchand (david.march...@redhat.com) changed: What|Removed |Added Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED CC||david.march...@redhat.com --- Comment #11 from David Marchand (david.march...@redhat.com) --- Fixed in https://git.dpdk.org/dpdk/commit/?id=011c617ca208 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1113] i40e: device configure ignores RSS key in rx_adv_conf
https://bugs.dpdk.org/show_bug.cgi?id=1113 Bug ID: 1113 Summary: i40e: device configure ignores RSS key in rx_adv_conf Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: ivan.ma...@oktetlabs.ru Target Milestone: --- Running the opensource ethdev test suite [1] on a i40e rig suggests that the PMD might have a bug in its device configure method. In particular, RSS key size and data passed by the caller as part of "rx_adv_conf" seem to be completely ignored. If the caller makes a mistake in the key size, they won't be informed about that. This way, the caller may be tricked into thinking that "rx_adv_conf" is accepted. However, if they try to predict a hash using this key, the result won't be valid. A log example can be found at [2]. [1] http://mails.dpdk.org/archives/dev/2022-October/251663.html [2] https://ts-factory.io/bublik/v2/log/70553?focusId=70999&mode=treeAndlog -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1006] [dpdk-22.03] [asan] coremask/individual_coremask: AddressSanitizer DEADLYSIGNAL
https://bugs.dpdk.org/show_bug.cgi?id=1006 jiang,yu (yux.ji...@intel.com) changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from jiang,yu (yux.ji...@intel.com) --- Fixed in dpdk22.11rc1 http://git.dpdk.org/dpdk/commit/?id=d5c398741dd243f737654d06d510be6b10385088 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1006] [dpdk-22.03] [asan] coremask/individual_coremask: AddressSanitizer DEADLYSIGNAL
https://bugs.dpdk.org/show_bug.cgi?id=1006 David Marchand (david.march...@redhat.com) changed: What|Removed |Added Resolution|FIXED |--- Assignee|dev@dpdk.org|yux.ji...@intel.com Status|RESOLVED|UNCONFIRMED CC||david.march...@redhat.com --- Comment #5 from David Marchand (david.march...@redhat.com) --- The mentionned commit is not related. Please double check, maybe you did not update the correct bz. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1114] build failures with clang 15
https://bugs.dpdk.org/show_bug.cgi?id=1114 Bug ID: 1114 Summary: build failures with clang 15 Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: alia...@nvidia.com Target Milestone: --- DPDK build fails with clang 15 in Fedora Rawhide due to unused variables: lib/eal/common/rte_service.c:110:6: error: variable 'count' set but not used [-Werror,-Wunused-but-set-variable] lib/vhost/virtio_net.c:1880:11: error: variable 'remained' set but not used [-Werror,-Wunused-but-set-variable] drivers/bus/dpaa/base/qbman/bman.h:522:6: error: variable 'aq_count' set but not used [-Werror,-Wunused-but-set-variable] (And in many other places). Probably caused by this change: https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html > -Wunused-but-set-variable now also warns if the variable is only used by > unary operators. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 993] [build][21.11] build failure using meson 0.62.0
https://bugs.dpdk.org/show_bug.cgi?id=993 Kevin Traynor (ktray...@redhat.com) changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||ktray...@redhat.com --- Comment #5 from Kevin Traynor (ktray...@redhat.com) --- This patch has been backported to 21.11 stable branch [1] and released as part of DPDK 21.11.1. Marking bug as RESOLVED as Reporter has confirmed this patch fixed the build. [1] https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=0c7cbe52f76963a6d8f6466fc077a9c0cb695b37 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1115] i40e: RSS hash conf update fails when hash proto mask in rx_adv_conf is 0
https://bugs.dpdk.org/show_bug.cgi?id=1115 Bug ID: 1115 Summary: i40e: RSS hash conf update fails when hash proto mask in rx_adv_conf is 0 Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: ivan.ma...@oktetlabs.ru Target Milestone: --- Opensource ethdev tests [1] have been improved over the past weeks. With the latest update, test "usecases/update_rss_hash_conf" finds yet another bug in i40e PMD. If the user has not passed a non-zero hash protocol mask via "rx_adv_conf" during device configure stage, any attempts to use rte_eth_dev_rss_hash_update() at a later stage will fail regardless of hash protocol mask and key being requested. When the test sees that, it tries to re-configure the ethdev, this time with the "rx_adv_conf" hash protocol mask being non-zero. The following invocations of rte_eth_dev_rss_hash_update() do not fail. In this particular case, the "non-zero" mask being used is in fact taken from the "flow_type_rss_offloads" field specified by the PMD. Further research indicates that the PMD considers RSS unconfigured in the case of zero "rx_adv_conf" hash protocol mask, which is not correct. Whether the user wants to enable RSS or not is determined solely by testing RTE_ETH_MQ_RX_RSS_FLAG in "rxmode.mq_mode" field. If this flag is set, rte_eth_dev_rss_hash_update() should not fail unless the application tries a wittingly unsupported configuration. A complete log example can be found at [2]. [1] http://mails.dpdk.org/archives/dev/2022-October/251663.html [2] https://ts-factory.io/bublik/v2/log/163204?focusId=163697&mode=treeAndlog -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1116] Failsafe PMD: Crashes with multiple secondary processes
https://bugs.dpdk.org/show_bug.cgi?id=1116
Bug ID: 1116
Summary: Failsafe PMD: Crashes with multiple secondary
processes
Product: DPDK
Version: 21.11
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: madhuker.myt...@oracle.com
Target Milestone: ---
On Hyper-V Linux VM's with failsafe/tap PMD crashes when we launch mutiple(two)
secondary processes.
Primary process able to launch well and then after when we launch secondary
processes, getting a crash on eal-intr-thread.
here are failure logs before crash:
EAL: Fail to recv reply for request
/var/run/dpdk/oracusbc/mp_socket:eal_dev_mp_request
EAL: Cannot send request to primary
EAL: Failed to send hotplug request to primary
net_failsafe: Failed to probe devargs net_tap_vsc0{*}
===
With DPDK-21.11 version.
Regards,
Madhuker.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1117] af-packet driver fix breaks rte_pktmbuf_prepend()
https://bugs.dpdk.org/show_bug.cgi?id=1117 Bug ID: 1117 Summary: af-packet driver fix breaks rte_pktmbuf_prepend() Product: DPDK Version: 21.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: bly...@gmail.com Target Milestone: --- The following commit causes rte_pktmbuf_prepend() to fail when prepending the full headroom reserved when creating the mbuf pool. https://git.dpdk.org/dpdk-stable/commit/?h=21.11&id=d41d39bcf76900deb6aa000e929fd65734254201 Of issue is if the received frame was originally tagged (and vlan-stripped by af-socket connection) the above commit does a vlan reinsert action as part of eth_af_packet_rx(). This moves the SOF forward into the "reserved" space by four bytes. For example, if the reserved space was 128 bytes and the next stage of processing is a generic pipeline handling a variety of interface types, the generic prepend of the reserved 128-byte meta-data space will fail. This means you cannot use a common pipeline and have to have an exception now for af-packet rx handling as compared to physical NIC, tap, vhost, etc. Ideally, the initial SOF offset should be consistent relative to your design's reserved headroom, regardless of the vlan tagged status of the frame or the interface type it was received on. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1101] [dpdk-22.11.0rc1][meson test] driver-tests/eventdev_selftest_sw test failed
https://bugs.dpdk.org/show_bug.cgi?id=1101 jiang,yu (yux.ji...@intel.com) changed: What|Removed |Added CC||yux.ji...@intel.com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from jiang,yu (yux.ji...@intel.com) --- Fixed in http://git.dpdk.org/dpdk/commit/?id=ab059e82e12f2a9dc7561960004819de68b37110 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1089] mlx5 Windows crash creating flows in multiple threads
https://bugs.dpdk.org/show_bug.cgi?id=1089 Tal Shnaiderman (tal...@nvidia.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Tal Shnaiderman (tal...@nvidia.com) --- Resolved in http://git.dpdk.org/dpdk/commit/?id=5976328d91c3616b1ad841a9181e1da23a2980bf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1118] [dpdk-22.11.0rc1][meson test] driver-tests/link_bonding_autotest test failed core dumped
https://bugs.dpdk.org/show_bug.cgi?id=1118
Bug ID: 1118
Summary: [dpdk-22.11.0rc1][meson test]
driver-tests/link_bonding_autotest test failed core
dumped
Product: DPDK
Version: 22.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: meson
Assignee: dev@dpdk.org
Reporter: weiyuanx...@intel.com
Target Milestone: ---
[Environment]
DPDK version: Use make showversion or for a non-released version: git remote -v
&& git show-ref --heads
dpdk22.11.0rc1 5976328d91c3616b1ad841a9181e1da23a2980bf
Other software versions: name/version for QEMU, OVS, etc. Repeat as required.
OS: Ubuntu 22.04.1 LTS (Jammy Jellyfish)/5.15.0-27-generic
Compiler: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
NIC hardware: Ethernet Controller XXV710 for 25GbE SFP28 158b.
NIC firmware:
driver: i40e
version: 5.15.0-27-generic
firmware-version: 9.00 0x8000cead 1.3179.0
[Test Setup]
Steps to reproduce
List the steps to reproduce the issue.
1. Use the following command to build DPDK:
CC=gcc meson -Denable_kmods=True -Dlibdir=lib --default-library=static
x86_64-native-linuxapp-gcc/
ninja -C x86_64-native-linuxapp-gcc/
2. Execute the following command in the dpdk directory.
MALLOC_PERTURB_=219 DPDK_TEST=link_bonding_autotest
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
MALLOC_PERTURB_=219 DPDK_TEST=link_bonding_rssconf_autotest
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
MALLOC_PERTURB_=219 DPDK_TEST=link_bonding_mode4_autotest
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
Show the output from the previous commands.
root@dpdk-VF-dut247:~/dpdk# MALLOC_PERTURB_=219
DPDK_TEST=link_bonding_rssconf_autotest
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
EAL: Detected CPU lcores: 72
EAL: Detected NUMA nodes: 2
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
APP: HPET is not enabled, using TSC as default timer
RTE>>link_bonding_rssconf_autotest
+ --- +
+ Test Suite : RSS Dynamic Configuration for Bonding Unit Test Suite
+ --- +
Floating point exception (core dumped)
root@dpdk-VF-dut247:~/dpdk# MALLOC_PERTURB_=219 DPDK_TEST=link_bonding_autotest
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
EAL: Detected CPU lcores: 72
EAL: Detected NUMA nodes: 2
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
APP: HPET is not enabled, using TSC as default timer
RTE>>link_bonding_autotest
+ --- +
+ Test Suite : Link Bonding Unit Test Suite
+ --- +
Floating point exception (core dumped)
root@dpdk-VF-dut247:~/dpdk# MALLOC_PERTURB_=219
DPDK_TEST=link_bonding_mode4_autotest
/root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff
EAL: Detected CPU lcores: 72
EAL: Detected NUMA nodes: 2
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'VA'
EAL: VFIO support initialized
APP: HPET is not enabled, using TSC as default timer
RTE>>link_bonding_mode4_autotest
+ --- +
+ Test Suite : Link Bonding mode 4 Unit Test Suite
Floating point exception (core dumped)
[Expected Result]
Explain what is the expected result in text or as an example output:
Test ok.
[Regression]
Is this issue a regression: (Y/N) Y
d03c0e83cc0042dc35e37f984de15533b09e6ac9 is the first bad commit
commit d03c0e83cc0042dc35e37f984de15533b09e6ac9
Author: Ivan Malov
Date: Sun Sep 11 15:19:01 2022 +0300
net/bonding: fix descriptor limit reporting
Commit 5be3b40fea60 ("net/bonding: fix values of descriptor limits")
breaks reporting of "nb_min" and "nb_align" values obtained from
back-end devices' descriptor limits. This means that work done
by eth_bond_slave_inherit_desc_lim_first() as well as
eth_bond_slave_inherit_desc_lim_next() gets dismissed.
Revert the offending commit and use proper workaround
for the test case mentioned in the said commit.
Meanwhile, the test case itself might be poorly constructed.
It tries to run a bond with no back-end devices attached,
but, according to [1] ("Requirements / Limitations"),
at least one back-end device must be attached.
[1] doc/guides/prog_guide/link_bonding_poll_mode_drv_lib.rst
Fixes: 5be3b40fea60 ("net/bonding: fix values of descriptor limits")
Cc: sta...@dpdk.org
Signed-off-by: Ivan Mal
[Bug 1119] [dpdk-22.11]pvp_virtio_bonding/vhost_virtio_bonding_mode_from_0_to_6: start bonding device failed and core dumped when quit testpmd
https://bugs.dpdk.org/show_bug.cgi?id=1119
Bug ID: 1119
Summary: [dpdk-22.11]pvp_virtio_bonding/vhost_virtio_bonding_mo
de_from_0_to_6: start bonding device failed and core
dumped when quit testpmd
Product: DPDK
Version: 22.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: dukaix.y...@intel.com
Target Milestone: ---
[Environment]
DPDK version:
DPDK 22.11-rc2
Other software versions: QEMU 7.1.0
OS:5.15.45-051545-generic
Compiler: gcc-11.2.0
Hardware platform: Intel(R) Xeon(R) Platinum 8280M CPU @ 2.70GHz
NIC hardware: Ethernet Controller XL710 for 40GbE QSFP+ 1583
NIC firmware: 9.00 0x8000c8d4 1.3179.0
NIC driver: I40e 2.20.12
[Test Setup]
Steps to reproduce
List the steps to reproduce the issue.
1.Bind 1 NIC port to vfio-pci:
usertools/dpdk-devbind.py --force --bind=vfio-pci :af:00.0
2.Start vhost testpmd:
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1-5 -n 4 -a :af:00.0
--file-prefix=vhost_61927_20221101094930 --vdev
'net_vhost0,iface=vhost-net0,client=1,queues=1' --vdev
'net_vhost1,iface=vhost-net1,client=1,queues=1' --vdev
'net_vhost2,iface=vhost-net2,client=1,queues=1' --vdev
'net_vhost3,iface=vhost-net3,client=1,queues=1' -- -i --port-topology=chained
--nb-cores=4 --txd=1024 --rxd=1024
testpmd> set fwd mac
testpmd> start
3.Start VM:
taskset -c 20,21,22,23,24,25,26,27 /home/QEMU/qemu-7.1.0/bin/qemu-system-x86_64
-name vm0 -enable-kvm -pidfile /tmp/.vm0.pid -daemonize -monitor
unix:/tmp/vm0_monitor.sock,server,nowait -netdev
user,id=nttsip1,hostfwd=tcp:10.239.252.214:6000-:22 -device
e1000,netdev=nttsip1 -cpu host -smp 6 -m 16384 -object
memory-backend-file,id=mem,size=16384M,mem-path=/mnt/huge,share=on -numa
node,memdev=mem -mem-prealloc -chardev
socket,path=/tmp/vm0_qga0.sock,server,nowait,id=vm0_qga0 -device virtio-serial
-device virtserialport,chardev=vm0_qga0,name=org.qemu.guest_agent.0 -vnc :4
-drive file=/home/image/ubuntu2004.img -chardev
socket,id=char0,path=./vhost-net0,server -netdev
type=vhost-user,id=netdev0,chardev=char0,vhostforce -device
virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01 -chardev
socket,id=char1,path=./vhost-net1,server -netdev
type=vhost-user,id=netdev1,chardev=char1,vhostforce -device
virtio-net-pci,netdev=netdev1,mac=52:54:00:00:00:02 -chardev
socket,id=char2,path=./vhost-net2,server -netdev
type=vhost-user,id=netdev2,chardev=char2,vhostforce -device
virtio-net-pci,netdev=netdev2,mac=52:54:00:00:00:03 -chardev
socket,id=char3,path=./vhost-net3,server -netdev
type=vhost-user,id=netdev3,chardev=char3,vhostforce -device
virtio-net-pci,netdev=netdev3,mac=52:54:00:00:00:04
4.Start testpmd in VM:
echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
echo 1024 >
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
umount `awk '/hugetlbfs/ { print $2 }' /proc/mounts`
mkdir -p /mnt/huge
mount -t hugetlbfs nodev /mnt/hugemodprobe vfio
modprobe vfio-pci
echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
usertools/dpdk-devbind.py --force --bind=vfio-pci :00:05.0 :00:06.0
:00:07.0 :00:08.0
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 0-5 -n 1 -a :00:05.0 -a
:00:06.0 -a :00:07.0 -a :00:08.0
--file-prefix=dpdk_61927_20221101095244-- -i --port-topology=chained
--nb-cores=5
testpmd> create bonded device 0 0
testpmd> add bonding slave 0 4
testpmd> add bonding slave 1 4
testpmd> add bonding slave 2 4
testpmd> port start 4
testpmd> show bonding config 4
testpmd> quit
[Show the output from the previous commands.]
root@virtiovm:~/dpdk# x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 0-5 -n 1
-a :00:05.0 -a :00:06.0 -a :00:07.0 -a :00:08.0
--file-prefix=dpdk_61927_20221101095244-- -i --port-topology=chained
--nb-cores=5
EAL: Detected CPU lcores: 6
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/dpdk_61927_20221101095244/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: VFIO support initialized
EAL: Probe PCI driver: net_virtio (1af4:1000) device: :00:05.0 (socket -1)
EAL: Using IOMMU type 8 (No-IOMMU)
EAL: Ignore mapping IO port bar(0)
EAL: Probe PCI driver: net_virtio (1af4:1000) device: :00:06.0 (socket -1)
EAL: Ignore mapping IO port bar(0)
EAL: Probe PCI driver: net_virtio (1af4:1000) device: :00:07.0 (socket -1)
EAL: Ignore mapping IO port bar(0)
EAL: Probe PCI driver: net_virtio (1af4:1000) device: :00:08.0 (socket -1)
EAL: Ignore mapping IO port bar(0)
Interactive-mode selected
Warning: NUMA should be configured manually by using --port-numa-config and
--ring-numa-config parameters along with --numa.
testpmd: create a new mbuf pool : n=187456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc
Configuring P
[Bug 1156] dpdk_flow_ops_fn api returns error for RSS queue action
https://bugs.dpdk.org/show_bug.cgi?id=1156
Bug ID: 1156
Summary: dpdk_flow_ops_fn api returns error for RSS queue
action
Product: DPDK
Version: 22.03
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: critical
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: ltham...@usc.edu
Target Milestone: ---
Created attachment 238
--> https://bugs.dpdk.org/attachment.cgi?id=238&action=edit
A temporary patch that solves the issue
Hi,
I would like to enable RSS on a set of queues of port through RTE flow.
For this I am calling dpdk_flow_ops_fn() by setting
vnet_flow_t flow;
flow.queue_index = start_queue_id;
flow.queue_num = end_queue_id - start_queue_id + 1;
flow.actions |= VNET_FLOW_ACTION_RSS;
But, dpdk_flow_ops_fn() returns VNET_FLOW_ERROR_NOT_SUPPORTED because it fails
the below condition:
switch (flow->type)
{
case VNET_FLOW_TYPE_ETHERNET:
case VNET_FLOW_TYPE_IP4:
case VNET_FLOW_TYPE_IP6:
case VNET_FLOW_TYPE_IP4_N_TUPLE:
case VNET_FLOW_TYPE_IP6_N_TUPLE:
case VNET_FLOW_TYPE_IP4_VXLAN:
case VNET_FLOW_TYPE_IP4_GTPC:
case VNET_FLOW_TYPE_IP4_GTPU:
case VNET_FLOW_TYPE_IP4_L2TPV3OIP:
case VNET_FLOW_TYPE_IP4_IPSEC_ESP:
case VNET_FLOW_TYPE_IP4_IPSEC_AH:
case VNET_FLOW_TYPE_GENERIC:
if ((rv = dpdk_flow_add (xd, flow, fe)))
goto done;
break;
default:
rv = VNET_FLOW_ERROR_NOT_SUPPORTED;
goto done;
}
It fails because flow->type is not one of above. The flow->type is set only if
a valid RTE flow pattern is required for the flow. For, RTE flows with RSS
Queue action, the pattern is not accepted. So, flow->type in this case should
be invalid (VNET_FLOW_TYPE_UNKNOWN).
If we try to program a RTE flow with some pattern and RSS Queue action, we get
below error.
DBGvpp# sh flow int TenGigabitEthernetb5/0/3
supported flow actions : count mark buffer-advance redirect-to-node
redirect-to-queue rss drop
last DPDK error type : 15
last DPDK error message : RSS Queues not supported when pattern specified
DBGvpp#
dpdk_flow_ops_fn() calls dpdk_flow_add(). Note that, even if dpdk_flow_ops_fn()
is bypassed, dpdk_flow_add() still fails because of the below conditions.
if (FLOW_IS_ETHERNET_CLASS (f))
flow_class = FLOW_ETHERNET_CLASS;
else if (FLOW_IS_IPV4_CLASS (f))
flow_class = FLOW_IPV4_CLASS;
else if (FLOW_IS_IPV6_CLASS (f))
flow_class = FLOW_IPV6_CLASS;
else
return VNET_FLOW_ERROR_NOT_SUPPORTED;
I have attached a patch that I have been using temporarily. Please check it out
and provide an official patch.
Thanks,
Nikhil
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1158] Mac address configuration on bonded device in 8023ad mode is not propagated to slave devices
https://bugs.dpdk.org/show_bug.cgi?id=1158 Bug ID: 1158 Summary: Mac address configuration on bonded device in 8023ad mode is not propagated to slave devices Product: DPDK Version: 22.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: k...@cesnet.cz Target Milestone: --- When you try to change the default mac address on a bonded device in 8023ad mode, the new mac address is not propagated to slave devices so packets with this new mac address are not delivered because they are dropped on the slave device. Steps to Reproduce in testpmd: dpdk-testpmd --log-level=pmd.net.bonding:debug -a :3b:00.0 -c 0x0f -n 4 --vdev 'net_bonding0,slave=:3b:00.0,mode=4,agg_mode=count' -- -i --port-topology=chained testpmd> port stop all testpmd> show bonding config 1 testpmd> set promisc 1 off testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 04:3F:72:C7:B8:84 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 04:3F:72:C7:B8:84 ... testpmd> port stop all testpmd> set bonding mac_addr 1 00:11:22:33:44:55 testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 04:3F:72:C7:B8:84 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 00:11:22:33:44:55 ... For comparison, the same steps for the bonded device in mode 0 (round-robin): dpdk-testpmd --log-level=pmd.net.bonding:debug -a :3b:00.1 -c 0x0f -n 4 --vdev 'net_bonding0,slave=:3b:00.1,mode=0' -- -i --port-topology=chained testpmd> port stop all testpmd> show bonding config 1 testpmd> set promisc 1 off testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 04:3F:72:C7:B8:85 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 04:3F:72:C7:B8:85 ... testpmd> port stop all testpmd> set bonding mac_addr 00:11:22:33:44:55 testpmd> port start all testpmd> show port info 0 * Infos for port 0 * MAC address: 00:11:22:33:44:55 ... testpmd> show port info 1 * Infos for port 1 * MAC address: 00:11:22:33:44:55 ... For comparison, configuring a bond device in 802.3ad mode using NMCLI: sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad" sudo nmcli connection modify bond0 ipv4.dhcp-timeout infinity sudo nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname ens1f0np0 master bond0 sudo ip address show bond0 11: bond0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 04:3f:72:c7:b8:84 brd ff:ff:ff:ff:ff:ff ... sudo ip link show ens1f0np0 6: ens1f0np0: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 04:3f:72:c7:b8:84 brd ff:ff:ff:ff:ff:ff ... sudo ip link set dev bond0 address 00:11:22:33:44:55 sudo ip link show bond0 11: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff ... sudo ip link show ens1f0np0 6: ens1f0np0: mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000 link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff permaddr 04:3f:72:c7:b8:84 ... [DPDK version] commit f262f16087ea6a77357a915cf4c0d10ddc7b6562 (HEAD, tag: v22.11, origin/releases) Author: Thomas Monjalon Date: Sun Nov 27 11:36:36 2022 +0100 version: 22.11.0 Signed-off-by: Thomas Monjalon [OS version] Operating System: Oracle Linux Server 8.7 Kernel: Linux 4.18.0-348.12.2.el8_5.x86_64 Architecture: x86-64 [Network devices] :3b:00.0 'MT2892 Family [ConnectX-6 Dx] 101d' if=ens1f0np0 drv=mlx5_core (802.3ad with LACP) :3b:00.1 'MT2892 Family [ConnectX-6 Dx] 101d' if=ens1f1np1 drv=mlx5_core -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1282] [openssl] dpdk-test-crypto-perf got stuck for multiple segments
https://bugs.dpdk.org/show_bug.cgi?id=1282 Bug ID: 1282 Summary: [openssl] dpdk-test-crypto-perf got stuck for multiple segments Product: DPDK Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: cryptodev Assignee: dev@dpdk.org Reporter: sbad...@nvidia.com Target Milestone: --- Created attachment 260 --> https://bugs.dpdk.org/attachment.cgi?id=260&action=edit test_aes_gcm.data file dpdk-test-crypto-perf got stuck when using openssl driver with multiple segments. To repro the issue, follow the steps below: * To run the app, use the following command: /download/dpdk/install/bin/dpdk-test-crypto-perf -c 0x7fff --vdev crypto_openssl,max_nb_queue_pairs=14 -- --ptest pmd-cyclecount --aead-op encrypt --optype aead --aead-algo aes-gcm --test-file /tmp/test_aes_gcm.data --test-name gcm --total-ops 837134 --aead-key-sz 32 --aead-iv-sz 12 --aead-aad-sz 334 --buffer-sz 256 --burst-sz 32 --digest-sz 16 --segment-sz 32 --devtype crypto_openssl --silent --csv-friendly startup log: EAL: Detected CPU lcores: 16 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' CRYPTODEV: Creating cryptodev crypto_openssl CRYPTODEV: Initialisation parameters - name: crypto_openssl,socket id: 0, max queue pairs: 14 Allocated pool "sess_mp_0" on socket 0 and the app got stuck. While for mlx driver: app command: /download/dpdk/install/bin/dpdk-test-crypto-perf -c 0x7fff -a :03:00.0,class=crypto,algo=1 -- --ptest pmd-cyclecount --aead-op encrypt --optype aead --aead-algo aes-gcm --test-file /tmp/test_aes_gcm.data --test-name gcm --total-ops 837134 --aead-key-sz 32 --aead-iv-sz 12 --aead-aad-sz 334 --buffer-sz 256 --burst-sz 32 --digest-sz 16 --segment-sz 32 --devtype mlx5_pci --silent --csv-friendly startup log: EAL: Detected CPU lcores: 16 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' EAL: Probe PCI driver: mlx5_pci (15b3:a2dc) device: :03:00.0 (socket -1) CRYPTODEV: Creating cryptodev mlx5_0 CRYPTODEV: Initialisation parameters - name: mlx5_0,socket id: -1, max queue pairs: 8 Allocated pool "sess_mp_0" on socket 0 # lcore id,Buf Size,Burst Size,Enqueued,Dequeued,Enq Retries,Deq Retries,Cycles/Op,Cycles/Enq,Cycles/Deq 2, 256,32,837134,837134,0,533741119,4.285,132.728,3266.640 5, 256,32,837134,837134,0,474591992,4.187,131.554,3267.847 1, 256,32,837134,837134,0,534222454,4.188,132.515,3267.158 14, 256,32,837134,837134,0,534253999,4.290,134.163,3266.250 8, 256,32,837134,837134,0,533930935,4.183,131.477,3268.442 10, 256,32,837134,837134,0,530621045,4.270,138.768,3261.594 7, 256,32,837134,837134,0,533981498,4.198,137.662,3263.727 3, 256,32,837134,837134,0,534203541,4.285,140.712,3258.738 9, 256,32,837134,837134,0,532553766,4.433,135.760,3262.361 4, 256,32,837134,837134,0,532835430,4.189,136.872,3263.587 11, 256,32,837134,837134,0,535932003,4.186,133.716,3265.873 12, 256,32,837134,837134,0,532764050,4.320,144.503,3254.523 13, 256,32,837134,837134,0,532940094,4.262,134.450,3264.728 6, 256,32,837134,837134,0,2301821,4.278,109.988,14.931 and it works fine when using a single segment with openssl driver: app command: /download/dpdk/install/bin/dpdk-test-crypto-perf -c 0x7fff --vdev crypto_openssl,max_nb_queue_pairs=14 -- --ptest pmd-cyclecount --aead-op encrypt --optype aead --aead-algo aes-gcm --test-file /tmp/test_aes_gcm.data --test-name gcm --total-ops 837134 --aead-key-sz 32 --aead-iv-sz 12 --aead-aad-sz 334 --buffer-sz 256 --burst-sz 32 --digest-sz 16 --segment-sz 272 --devtype crypto_openssl --silent --csv-friendly--silent startup log: EAL: Detected CPU lcores: 16 EAL: Detected NUMA nodes: 1 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' CRYPTODEV: Creating cryptodev crypto_openssl CRYPTODEV: Initialisation parameters - name: crypto_openssl,socket id: 0, max queue pairs: 14 Allocated pool "sess_mp_0" on socket 0 # lcore id,Buf Size,Burst Size,Enqueued,Dequeued,Enq Retries,Deq Retries,Cycles/Op,Cycles/Enq,Cycles/Deq 14, 256,32,837134,837134,408,0,2.392,753.011,1.399 13, 256,32,837134,837134,408,0,2.380,805.099,1.418 12, 256,32,837134,837134,408,0,2.403,805.045,1.371 9, 256,32,837134,837134,408,0,2.394,805.847,1.357 8, 256,32,837134,837134,408,0,2.393,809.166,1.392 4, 256,32,837134,837134,408,0,2.389,816.142,1.320 5, 256,32,837134,83713
[Bug 1283] Failing to compile testpmd on Windows
https://bugs.dpdk.org/show_bug.cgi?id=1283 Bug ID: 1283 Summary: Failing to compile testpmd on Windows Product: DPDK Version: 23.11 Hardware: x86 OS: Windows Status: UNCONFIRMED Severity: critical Priority: Normal Component: testpmd Assignee: dev@dpdk.org Reporter: pdamo...@nvidia.com Target Milestone: --- when i do 1. "C:\Program Files\Meson\meson.exe" --buildtype debug "-Dc_args=-I\"C:\Program Files\Mellanox\MLNX_WinOF2_DevX_SDK\inc\"" "-Dc_link_args=-L\"C:\Program Files\Mellanox\MLNX_WinOF2_DevX_SDK\lib\"" "-Dexamples=udpfwd,flow_filtering,l2fwd,l2fwd_default_flow,helloworld,udpfwd_rss,l2fwd_master,udpfwd_rx_tx_cheksum,l2fwd_rss" build 2. ninja i get FAILED: drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj clang @drivers/common/idpf/6e54547@@idpf_common_avx512_lib@sta/idpf_common_rxtx_avx512.c.obj.rsp In file included from ../drivers/common/idpf/idpf_common_rxtx_avx512.c:6: In file included from ..\drivers\common\idpf/idpf_common_device.h:9: In file included from ..\drivers\common\idpf/base/idpf_prototype.h:9: In file included from ..\drivers\common\idpf/base/idpf_osdep.h:18: In file included from ..\lib\eal\include\rte_malloc.h:16: In file included from ..\lib\eal\include\rte_memory.h:25: In file included from ..\lib\eal\include\rte_fbarray.h:39: In file included from ..\lib\eal\x86\include\rte_rwlock.h:13: In file included from ..\lib\eal\x86\include/rte_spinlock.h:18: In file included from ..\lib\eal\x86\include/rte_cycles.h:12: In file included from C:\Program Files\LLVM\lib\clang\11.0.0\include\x86intrin.h:24: C:\Program Files\LLVM\lib\clang\11.0.0\include\prfchwintrin.h:50:1: error: conflicting types for '__m_prefetchw' _m_prefetchw(void *__P) ^ ..\lib\eal\windows\include\rte_windows.h:28:22: note: expanded from macro '_m_prefetchw' #define _m_prefetchw __m_prefetchw ^ C:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um\winnt.h:3538:1: note: previous declaration is here _m_prefetchw ( ^ ..\lib\eal\windows\include\rte_windows.h:28:22: note: expanded from macro '_m_prefetchw' #define _m_prefetchw __m_prefetchw ^ 1 error generated. [131/810] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_devx_cmds.c.obj ninja: build stopped: subcommand failed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1273] eth_memif_rx segfault when burst size is greater than 32
https://bugs.dpdk.org/show_bug.cgi?id=1273 JoyceKong (joyce.k...@arm.com) changed: What|Removed |Added Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #5 from JoyceKong (joyce.k...@arm.com) --- https://patches.dpdk.org/project/dpdk/patch/20230904071041.3403495-1-joyce.k...@arm.com/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1273] eth_memif_rx segfault when burst size is greater than 32
https://bugs.dpdk.org/show_bug.cgi?id=1273 David Marchand (david.march...@redhat.com) changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|CONFIRMED CC||david.march...@redhat.com --- Comment #6 from David Marchand (david.march...@redhat.com) --- This patch is not merged. Don't mark as resolved until the fix makes it into DPDK. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1286] cksum
https://bugs.dpdk.org/show_bug.cgi?id=1286
Bug ID: 1286
Summary: cksum
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: wa...@3snic.com
Target Milestone: ---
The code making sure sctp payload be multiple of 4 to determin TX_SCP_CKSUM in
process_inner_cksums() of csumonly.c should convert ipv4_hdr->total_length to
host byte order. The following is the code segment.
```
} else if (info->l4_proto == IPPROTO_SCTP) {
sctp_hdr = (struct rte_sctp_hdr *)
((char *)l3_hdr + info->l3_len);
/* sctp payload must be a multiple of 4 to be
* offloaded */
if ((tx_offloads & RTE_ETH_TX_OFFLOAD_SCTP_CKSUM) &&
((ipv4_hdr->total_length & 0x3) == 0)) {
ol_flags |= RTE_MBUF_F_TX_SCTP_CKSUM;
} else {
sctp_hdr->cksum = 0;
/* XXX implement CRC32c, example available in
* RFC3309 */
}
}
```
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1288] af_packet do not support multi-process
https://bugs.dpdk.org/show_bug.cgi?id=1288 Bug ID: 1288 Summary: af_packet do not support multi-process Product: DPDK Version: 21.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: 779198...@qq.com Target Milestone: --- hi,I'm recently have problem in using af_packet,I wanna do init in primary program and do rx_pkt_burst in secondary,so that I can make primary more stable,however, when change eth1 to af_packet, it cause coredump,and when I gdb ,it shows rx_pkt_burst is not init in secondary. does the af_packet only support primary do rx_pkt_burst? is there any way if I want to do rx_pkt_burst in a secondary program? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1289] rte_table: lookup functions have UB for ctz
https://bugs.dpdk.org/show_bug.cgi?id=1289 Bug ID: 1289 Summary: rte_table: lookup functions have UB for ctz Product: DPDK Version: 23.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: qrea...@gmail.com Target Milestone: --- Macros 'lookup2_stage0_with_odd_support' can call rte_ctz with zero value (pkt_mask), which is undefined behaviour based on the GCC manual: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Quote: " Built-in Function: int __builtin_ctz (unsigned int x) Returns the number of trailing 0-bits in x, starting at the least significant bit position. If x is 0, the result is undefined. " It is confirmed by checking this code in GCC-13 with ASAN. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1290] rte_exit will hang if called from worker or service thread
https://bugs.dpdk.org/show_bug.cgi?id=1290
Bug ID: 1290
Summary: rte_exit will hang if called from worker or service
thread
Product: DPDK
Version: 23.07
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: core
Assignee: dev@dpdk.org
Reporter: step...@networkplumber.org
Target Milestone: ---
Calling rte_exit in a thread other than main thread won't work because
the cleanup code is calling rte_eal_cleanup, and inside that it ends
up waiting for all workers. Since the thread you are calling from
is a worker, it ends up waiting for itself.
rte_exit()
rte_eal_cleanup()
rte_service_finalize()
rte_eal_mp_wait_lcore()
void
rte_eal_mp_wait_lcore(void)
{
unsigned lcore_id;
RTE_LCORE_FOREACH_WORKER(lcore_id) {
rte_eal_wait_lcore(lcore_id);
}
}
Either service handling needs to be smarter, the rte_exit() function
check if it is called from main lcore, and/or documentation needs update.
Not a simple fix because in order to safely do the cleanup logic
all threads have to gone to a quiescent state.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 1291] Invalid pcapng timestamp
https://bugs.dpdk.org/show_bug.cgi?id=1291 Bug ID: 1291 Summary: Invalid pcapng timestamp Product: DPDK Version: 23.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: joonmo@ericsson.com Target Milestone: --- Hi, rte_pcapng_copy() is called with rte_get_tsc_cycles(). And, if pcapng isn't initialized, pcapng_init() is called. rte_get_tsc_cyles() is called during pcapng_init for base time. But, cycles on pcapng_init() is later cycle than parameter of rte_pcapng_copy() in this case. So, delta value of pcapng_tsc_to_ns() will be negative value. But, delta value type is uint64_t. It will cause incorrect timestamp. Maybe, I'm thinking that pcapng_init() should be called before rte_pcapng_copy(). Joonmo Koo -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1292] mbuf: L2 packet type names could be improved
https://bugs.dpdk.org/show_bug.cgi?id=1292 Bug ID: 1292 Summary: mbuf: L2 packet type names could be improved Product: DPDK Version: 23.11 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: m...@smartsharesystems.com Target Milestone: --- In rte_mbuf_ptype.h, having both L2 and ETHER in the Ethernet packet type names seems redundant. RTE_PTYPE_L2_ETHER(_TIMESYNC|_ARP|_LLDP, etc.) could simply be RTE_PTYPE_L2(_TIMESYNC|_ARP|_LLDP, etc.). Furthermore, RTE_PTYPE_L2_ETHER defines IP (both v4 and v6) packets, so IP should be part of the name, e.g. RTE_PTYPE_L2_ETHER_IP. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1293] how to free mempool in secondary as prev process exit unnormally without calling free function
https://bugs.dpdk.org/show_bug.cgi?id=1293 Bug ID: 1293 Summary: how to free mempool in secondary as prev process exit unnormally without calling free function Product: DPDK Version: 21.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: 779198...@qq.com Target Milestone: --- hi, I recently using dpdk primary as a stable program that won't exit maybe for a month, so i need do rx_burst in a secondary program,however, cause the secondary does a lot work and it may exit at any time,and restart, here is my question: 1.how to smoothly free or reset the ring,mempoop,zone and rte_ip_frag_tbl before my secondary process start up at next time? 2.what can i do to prevent memery leaking as my secondary process would restart many times? very much looking forword your reply. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 1294] recieve sig 11 when call rte_ip_frag_table_create on primary forked process
https://bugs.dpdk.org/show_bug.cgi?id=1294 Bug ID: 1294 Summary: recieve sig 11 when call rte_ip_frag_table_create on primary forked process Product: DPDK Version: 21.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: 779198...@qq.com Target Milestone: --- hi,my team is going do our own business in primary forked process, to make sure business won't affect the primary, we may refork the business process many times, now there comes the problem: when the first time fork the process ,it runs good, but, it recieved sig-11 on call rte_ip_frag_table_create after the second time fork. here is the backtrace: (gdb) bt #0 0x7fb913af4dc5 in malloc_elem_insert () from /lib/libdpdk.so #1 0x7fb913af5e97 in alloc_pages_on_heap () from /lib/libdpdk.so #2 0x7fb913af6154 in try_expand_heap () from /lib/libdpdk.so #3 0x7fb913af65a1 in alloc_more_mem_on_socket () from /lib/libdpdk.so #4 0x7fb913af6c9a in malloc_heap_alloc () from /lib/libdpdk.so #5 0x7fb913af84e3 in rte_malloc_socket () from /lib/libdpdk.so #6 0x7fb913af863f in rte_zmalloc_socket () from /lib/libdpdk.so #7 0x7fb913a4343f in rte_ip_frag_table_create () from /lib/libdpdk.so does the primary do not allow malloc and free memery at forking process? could you do me a favor? thanks -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 676] Cryptodev test build warning on Fedora 34
https://bugs.dpdk.org/show_bug.cgi?id=676
Bug ID: 676
Summary: Cryptodev test build warning on Fedora 34
Product: DPDK
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: cryptodev
Assignee: dev@dpdk.org
Reporter: kevu...@gmail.com
Target Milestone: ---
Cryptodev tests have build warnings on Fedora-34_Beta-1.3 with the latest
packages.
[kevin@fedora ~]$ cat /etc/redhat-release
Fedora release 34 (Thirty Four)
[kevin@fedora ~]$ uname -a
Linux fedora 5.11.13-300.fc34.x86_64 #1 SMP Sun Apr 11 15:07:42 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
[kevin@fedora ~]$ gcc --version
gcc (GCC) 11.0.1 20210324 (Red Hat 11.0.1-0)
591/2712] Compiling C object app/test/dpdk-test.p/test_cryptodev.c.o
../app/test/test_cryptodev.c: In function ‘test_multi_session’:
../app/test/test_cryptodev.c:10448:9: warning: array subscript ‘struct
rte_cryptodev_sym_session *[4]’ is partly outside array bounds of ‘unsigned
char[33]’ [-Warray-bounds]
10448 | rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
| ^~~~
10449 | sessions[i], &ut_params->auth_xform,
|
10450 | ts_params->session_priv_mpool);
| ~~
../app/test/test_cryptodev.c:10400:20: note: referencing an object of size 33
allocated by ‘rte_malloc’
10400 | sessions = rte_malloc(NULL,
|^~~~
10401 | (sizeof(struct rte_cryptodev_sym_session *) *
| ~
10402 | MAX_NB_SESSIONS) + 1, 0);
|
In file included from ../app/test/test.h:25,
from ../app/test/test_cryptodev.c:29:
../app/test/test_cryptodev.c:10451:34: warning: array subscript ‘struct
rte_cryptodev_sym_session *[4]’ is partly outside array bounds of ‘unsigned
char[33]’ [-Warray-bounds]
10451 | TEST_ASSERT_NULL(sessions[i],
| ^~~
../lib/librte_eal/include/rte_test.h:20:15: note: in definition of macro
‘RTE_TEST_ASSERT’
20 | if (!(cond)) {
\
| ^~~~
../app/test/test.h:103:26: note: in expansion of macro ‘RTE_TEST_ASSERT_NULL’
103 | #define TEST_ASSERT_NULL RTE_TEST_ASSERT_NULL
| ^~~~
../app/test/test_cryptodev.c:10451:9: note: in expansion of macro
‘TEST_ASSERT_NULL’
10451 | TEST_ASSERT_NULL(sessions[i],
| ^~~~
../app/test/test_cryptodev.c:10400:20: note: referencing an object of size 33
allocated by ‘rte_malloc’
10400 | sessions = rte_malloc(NULL,
|^~~~
10401 | (sizeof(struct rte_cryptodev_sym_session *) *
| ~
10402 | MAX_NB_SESSIONS) + 1, 0);
|
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 677] table test build warning on Fedora 34
https://bugs.dpdk.org/show_bug.cgi?id=677 Bug ID: 677 Summary: table test build warning on Fedora 34 Product: DPDK Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: kevu...@gmail.com Target Milestone: --- table tests have build warnings on Fedora-34_Beta-1.3 with the latest packages. [kevin@fedora ~]$ cat /etc/redhat-release Fedora release 34 (Thirty Four) [kevin@fedora ~]$ uname -a Linux fedora 5.11.13-300.fc34.x86_64 #1 SMP Sun Apr 11 15:07:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [kevin@fedora ~]$ gcc --version gcc (GCC) 11.0.1 20210324 (Red Hat 11.0.1-0) [2662/2712] Compiling C object app/test/dpdk-test.p/test_table_tables.c.o ../app/test/test_table_tables.c: In function ‘test_table_stub’: ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:151:25: note: in expansion of macro ‘PREPARE_PACKET’ 151 | PREPARE_PACKET(mbufs[i], 0xadadadad); | ^~ ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:153:25: note: in expansion of macro ‘PREPARE_PACKET’ 153 | PREPARE_PACKET(mbufs[i], 0xadadadab); | ^~ ../app/test/test_table_tables.c: In function ‘test_table_hash_lru_generic’: ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:714:25: note: in expansion of macro ‘PREPARE_PACKET’ 714 | PREPARE_PACKET(mbufs[i], 0xadadadad); | ^~ ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:716:25: note: in expansion of macro ‘PREPARE_PACKET’ 716 | PREPARE_PACKET(mbufs[i], 0xadadadab); | ^~ ../app/test/test_table_tables.c: In function ‘test_table_hash_ext_generic’: ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:824:25: note: in expansion of macro ‘PREPARE_PACKET’ 824 | PREPARE_PACKET(mbufs[i], 0xadadadad); | ^~ ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:826:25: note: in expansion of macro ‘PREPARE_PACKET’ 826 | PREPARE_PACKET(mbufs[i], 0xadadadab); | ^~ ../app/test/test_table_tables.c: In function ‘test_table_array’: ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:261:25: note: in expansion of macro ‘PREPARE_PACKET’ 261 | PREPARE_PACKET(mbufs[i], 10); | ^~ ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:263:25: note: in expansion of macro ‘PREPARE_PACKET’ 263 | PREPARE_PACKET(mbufs[i], 20); | ^~ ../app/test/test_table_tables.c: In function ‘test_table_lpm_ipv6’: ../app/test/test_table_tables.c:31:9: warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0] [-Warray-bounds] 31 | memset(key, 0, 32); \ | ^~ ../app/test/test_table_tables.c:610:25: note: in expansion of macro ‘PREPA
[dpdk-dev] [Bug 678] ice build warnings on Fedora 34 with gcc11
https://bugs.dpdk.org/show_bug.cgi?id=678 Bug ID: 678 Summary: ice build warnings on Fedora 34 with gcc11 Product: DPDK Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: kevu...@gmail.com CC: alia...@nvidia.com, david.march...@redhat.com, kevu...@gmail.com, konstantin.anan...@intel.com Depends on: 673 Target Milestone: --- +++ This bug was initially created as a clone of Bug #673 +++ https://bugs.dpdk.org/show_bug.cgi?id=673#c2 describes ice build failures on Fedora35. These are also present on Fedora 34 Beta. [kevin@fedora ~]$ cat /etc/redhat-release Fedora release 34 (Thirty Four) [kevin@fedora ~]$ uname -a Linux fedora 5.11.13-300.fc34.x86_64 #1 SMP Sun Apr 11 15:07:42 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux [kevin@fedora ~]$ gcc --version gcc (GCC) 11.0.1 20210324 (Red Hat 11.0.1-0) [1447/2712] Compiling C object drivers/net/ice/base/libice_base.a.p/ice_switch.c.o In file included from ../drivers/net/ice/base/ice_osdep.h:20, from ../drivers/net/ice/base/ice_type.h:54, from ../drivers/net/ice/base/ice_common.h:8, from ../drivers/net/ice/base/ice_switch.h:8, from ../drivers/net/ice/base/ice_switch.c:5: ../drivers/net/ice/base/ice_switch.c: In function ‘ice_create_pkt_fwd_rule’: ../drivers/net/ice/base/ice_switch.c:3998:35: warning: array subscript ‘struct ice_aqc_sw_rules_elem[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Warray-bounds] 3998 | LE16_TO_CPU(s_rule->pdata.lkup_tx_rx.index); | ^~ ../lib/librte_eal/x86/include/rte_byteorder.h:81:30: note: in definition of macro ‘rte_le_to_cpu_16’ 81 | #define rte_le_to_cpu_16(x) (x) | ^ ../drivers/net/ice/base/ice_switch.c:3998:17: note: in expansion of macro ‘LE16_TO_CPU’ 3998 | LE16_TO_CPU(s_rule->pdata.lkup_tx_rx.index); | ^~~ In file included from ../drivers/net/ice/base/ice_type.h:54, from ../drivers/net/ice/base/ice_common.h:8, from ../drivers/net/ice/base/ice_switch.h:8, from ../drivers/net/ice/base/ice_switch.c:5: ../drivers/net/ice/base/ice_osdep.h:209:29: note: referencing an object of size 32 allocated by ‘rte_zmalloc’ 209 | #define ice_malloc(h, s)rte_zmalloc(NULL, s, 0) | ^~~ ../drivers/net/ice/base/ice_switch.c:3969:17: note: in expansion of macro ‘ice_malloc’ 3969 | ice_malloc(hw, ICE_SW_RULE_RX_TX_ETH_HDR_SIZE); | ^~ ../drivers/net/ice/base/ice_switch.c: In function ‘ice_update_pkt_fwd_rule’: ../drivers/net/ice/base/ice_switch.c:3610:22: warning: array subscript ‘struct ice_aqc_sw_rules_elem[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Warray-bounds] 3610 | s_rule->type = (f_info->flag & ICE_FLTR_RX) ? In file included from ../drivers/net/ice/base/ice_type.h:54, from ../drivers/net/ice/base/ice_common.h:8, from ../drivers/net/ice/base/ice_switch.h:8, from ../drivers/net/ice/base/ice_switch.c:5: ../drivers/net/ice/base/ice_osdep.h:209:29: note: referencing an object of size 32 allocated by ‘rte_zmalloc’ 209 | #define ice_malloc(h, s)rte_zmalloc(NULL, s, 0) | ^~~ ../drivers/net/ice/base/ice_switch.c:4027:17: note: in expansion of macro ‘ice_malloc’ 4027 | ice_malloc(hw, ICE_SW_RULE_RX_TX_ETH_HDR_SIZE); | ^~ ../drivers/net/ice/base/ice_switch.c:3615:44: warning: array subscript ‘struct ice_aqc_sw_rules_elem[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Warray-bounds] 3615 | s_rule->pdata.lkup_tx_rx.recipe_id = CPU_TO_LE16(f_info->lkup_type); In file included from ../drivers/net/ice/base/ice_type.h:54, from ../drivers/net/ice/base/ice_common.h:8, from ../drivers/net/ice/base/ice_switch.h:8, from ../drivers/net/ice/base/ice_switch.c:5: ../drivers/net/ice/base/ice_osdep.h:209:29: note: referencing an object of size 32 allocated by ‘rte_zmalloc’ 209 | #define ice_malloc(h, s)rte_zmalloc(NULL, s, 0) | ^~~ ../drivers/net/ice/base/ice_switch.c:4027:17: note: in expansion of macro ‘ice_malloc’ 4027 | ice_malloc(hw, ICE_SW_RULE_RX_TX_ETH_HDR_SIZE); | ^~ ../drivers/net/ice/base/ice_switch.c:3616:38: warning: array subscript ‘struct ice_aqc_sw_rules_elem[0]’ is partly outside array bounds of ‘unsigned char[32]’ [-Warray-bounds] 3616 | s_
[dpdk-dev] [Bug 680] [dpdk-21.05]hotplug_mp/test_attach_detach_dev_primary_cross_loop: Segmentation fault when detach device
https://bugs.dpdk.org/show_bug.cgi?id=680 Bug ID: 680 Summary: [dpdk-21.05]hotplug_mp/test_attach_detach_dev_primary_ cross_loop: Segmentation fault when detach device Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: leweix.y...@intel.com Target Milestone: --- Environment DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads 21.05.0-rc0:89813a522e68076e6f50ec18b075fa57cc5ae937 Other software versions: name/version for QEMU, OVS, etc. Repeat as required. OS: CentOS Stream 8 4.18.0-269.el8.x86_64 Compiler: gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1) Hardware platform: Intel(R) Xeon(R) Gold 6252N CPU @ 2.30GHz NIC hardware: XXV710 for 25GbE SFP28 158b Driver version: 2.8.20-k NIC firmware: 8.00 0x80008bb1 1.2766.0 Test Setup Steps to reproduce List the steps to reproduce the issue. 1. build dpdk # rm -rf x86_64-native-linuxapp-gcc # CC=gcc meson --werror -Denable_kmods=True -Dlibdir=lib -Dc_args='-DRTE_EAL_IGB_UIO=1' --default-library=static x86_64-native-linuxapp-gcc # ninja -C x86_64-native-linuxapp-gcc -j 70 # meson configure -Dexamples=multi_process/hotplug_mp x86_64-native-linuxapp-gcc # ninja -C x86_64-native-linuxapp-gcc 2. lanch app # Open three dut terminals # terminal1：x86_64-native-linuxapp-gcc/examples/dpdk-hotplug_mp --proc-type=auto # terminal2：x86_64-native-linuxapp-gcc/examples/dpdk-hotplug_mp --proc-type=auto # terminal3：x86_64-native-linuxapp-gcc/examples/dpdk-hotplug_mp --proc-type=auto # terminal1：list # terminal2：list # terminal3：list # terminal1：attach :18:00.0 # terminal1：list # terminal2：list # terminal3：list # terminal3: detach :18:00.0 Show the output from the previous commands: Output of Terninal3: Failed to send hotplug request to primary. example> detach :18:00.0 detaching... EAL: Releasing PCI mapped resource for :18:00.0 EAL: Calling pci_unmap_resource for :18:00.0 at 0x22 EAL: Calling pci_unmap_resource for :18:00.0 at 0x220100 EAL: Fail to recv reply for request /var/run/dpdk/rte/mp_socket:eal_dev_mp_request EAL: Cannot send request to primary EAL: Failed to send hotplug request to primary failed to dettach device :18:00.0 Output of Terninal2: example> list list all etherdev 0 :18:00.0 example> EAL: Releasing PCI mapped resource for :18:00.0 EAL: Calling pci_unmap_resource for :18:00.0 at 0x22 EAL: Calling pci_unmap_resource for :18:00.0 at 0x220100 example> list list all etherdev example> Output of Terninal1: will shouw "segmentation fault" example> EAL: Releasing PCI mapped resource for :18:00.0 EAL: Calling pci_unmap_resource for :18:00.0 at 0x22 EAL: Calling pci_unmap_resource for :18:00.0 at 0x220100 Segmentation fault (core dumped) Expected Result Explain what is the expected result in text or as an example output: detaching... EAL: Releasing PCI mapped resource for :18:00.0 EAL: Calling pci_unmap_resource for :18:00.0 at 0x22 EAL: Calling pci_unmap_resource for :18:00.0 at 0x220100 detached device :18:00.0 Regression Is this issue a regression: (Y/N) Y Bad commitid : 64051bb1f144c418f3fc76e6d0973337b05d5886 git show 64051bb1f144c418f3fc76e6d0973337b05d5886 commit 64051bb1f144c418f3fc76e6d0973337b05d5886 (HEAD) Author: Xueming Li Date: Tue Apr 13 03:14:08 2021 + devargs: unify scratch buffer storage In current design, legacy parser rte_devargs_parse() saved scratch buffer to devargs.args while new parser rte_devargs_layers_parse() saved to devargs.data. Code using devargs had to know the difference and cleaned up memory accordingly - error prone. This patch unifies scratch buffer to data field, introduces rte_devargs_reset() function to wrap the memory clean up logic. Signed-off-by: Xueming Li Acked-by: Ray Kinsella Reviewed-by: Gaetan Rivet -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 681] DPDK 20.11.1 failed to build for x86 machine types
https://bugs.dpdk.org/show_bug.cgi?id=681
Bug ID: 681
Summary: DPDK 20.11.1 failed to build for x86 machine types
Product: DPDK
Version: 20.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: meson
Assignee: dev@dpdk.org
Reporter: qlinq...@yahoo.com
Target Milestone: ---
While build with commands:
meson build
meson -Dmachine=atom
works fine, build with x86 machine types failed. e.g.
meson -Dmachine=silvermont
The problem seems with compiler setting. File
$(DPDK_ROOT)/config/x86/meson.build has code:
# we require SSE4.2 for DPDK
if cc.get_define('__SSE4_2__', args: machine_args) == ''
message('SSE 4.2 not enabled by default, explicitly enabling')
machine_args += '-msse4'
endif
The error is: "Could not get define '__SSE4_2__' "
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 682] [dpdk-21.05]metering_and_policing: Invalid group ID: Invalid argument
https://bugs.dpdk.org/show_bug.cgi?id=682 Bug ID: 682 Summary: [dpdk-21.05]metering_and_policing: Invalid group ID: Invalid argument Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: longfengx.li...@intel.com Target Milestone: --- Environment DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads 21.05.0-rc0:1cd3ce09534e035b3b3cfe0475adee656971fd8c Other software versions: name/version for QEMU, OVS, etc. Repeat as required. OS: Fedora 33 5.9.10-200.fc33.x86_64 Compiler: gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6) Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz NIC hardware: XL710 for 40GbE QSFP+ Driver version: 2.15.9 NIC firmware: 8.30 0x8000a4ae 1.2926.0 Test Setup Steps to reproduce List the steps to reproduce the issue. 1. build dpdk # rm -rf x86_64-native-linuxapp-gcc # CC=gcc meson --werror -Denable_kmods=True -Dlibdir=lib -Dc_args='-DRTE_EAL_IGB_UIO=1' --default-library=static x86_64-native-linuxapp-gcc # ninja -C x86_64-native-linuxapp-gcc -j 70 2. tester preparation # scp -v .dts/dep/meter_and_policy_config.tar.gz root@10.240.183.141:/tmp 3. DUT preparation # ./usertools/dpdk-devbind.py -b vfio-pci :84:00.0 :84:00.1 # tar xf /tmp/meter_and_policy_config.tar.gz -C /root/dpdk/drivers/net/softnic # cp /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*link LINK0 dev.*$/link LINK0 dev :84:00.0/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*link LINK1 dev.*$/link LINK1 dev :84:00.1/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*table action profile AP0.*$/table action profile AP0 ipv4 offset 270 fwd meter trtcm tc 1 stats pkts/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*pipeline RX table match.*$/pipeline RX table match acl ipv4 offset 270 size 4K action AP0/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/thread 5 pipeline RX enable/thread 2 pipeline RX enable/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/thread 5 pipeline TX enable/thread 2 pipeline TX enable/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 4. lanch app # x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 0,1,2 -n 4 -a :84:00.0 -a :84:00.1 --file-prefix=dpdk_18582_20210418103702 -s 0x4 --vdev 'net_softnic0,firmware=/root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5' -- -i --rxq=2 --txq=2 --portmask=0x4 --disable-rss # add port meter profile trtcm_rfc2698 2 0 312500 312500 400 500 # create port meter 2 0 0 yes d d d 0 0 0 # flow create 2 group 0 ingress pattern eth / ipv4 proto mask 255 src mask 255.255.255.255 dst mask 255.255.255.255 src spec 1.10.11.12 dst spec 2.20.21.22 proto spec 6 / tcp src mask 65535 dst mask 65535 src spec 2 dst spec 2 / end actions meter mtr_id 0 / queue index 0 / end Show the output from the previous commands. # testpmd> add port meter profile trtcm_rfc2698 2 0 312500 312500 400 500 Bad arguments # testpmd> create port meter 2 0 0 yes d d d 0 0 0 meter profile id: Meter profile id not valid (error 2) # testpmd> flow create 2 group 0 ingress pattern eth / ipv4 proto mask 255 src mask 255.255.255.255 dst mask 255.255.255.255 src spec 1.10.11.12 dst spec 2.20.21.22 proto spec 6 / tcp src mask 65535 dst mask 65535 src spec 2 dst spec 2 / end actions meter mtr_id 0 / queue index 0 / end port_flow_complain(): Caught PMD error type 3 (group field): cause: 0x7ffe0125f3c8, Invalid group ID: Invalid argument # testpmd> EAL: Error reading from file descriptor 23: Input/output error EAL: Error reading from file descriptor 26: Input/output error Killed Expected Result Explain what is the expected result in text or as an example output: # testpmd> add port meter profile trtcm_rfc2698 2 0 312500 312500 400 500 # testpmd> create port meter 2 0 0 yes d d d 0 0 0 # testpmd> flow create 2 group 0 ingress pattern eth / ipv4 proto mask 255 src mask 255.255.255.255 dst mask 255.255.255.255 src spec 1.10.11.12 dst spec 2.20.21.22 proto spec 6 / tcp src mask 65535 dst mask 65535 src spec 2 dst spec 2 / end actions meter mtr_id 0 / queue index 0 / end Flow rule #0 created Regression Is this issue a regression: (Y/N) Y [root@localhost dpdk]# git show c5a3860f36902e1701817b0961bf99a5c96ede3a commit c5a3860f36902e1701817b0961bf99a5c96ede3a (HEAD) Author: Li Zhang Date: Tue Apr 13 18:59:55 2021 +0300 app/testpmd: add meter profile packet mode option add meter profile packet_mode to the ethernet device. One example: add port meter
[dpdk-dev] [Bug 682] [dpdk-21.05]metering_and_policing: Invalid group ID: Invalid argument
https://bugs.dpdk.org/show_bug.cgi?id=682 longfengx.li...@intel.com (longfengx.li...@intel.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from longfengx.li...@intel.com (longfengx.li...@intel.com) --- It seems following cmd has been updated, a param 'packet_mode' must be added testpmd> add port meter profile trtcm_rfc2698 (port_id) (profile_id) \ - (cir) (pir) (cbs) (pbs) + (cir) (pir) (cbs) (pbs) (packet_mode) set cmd： 'add port meter profile trtcm_rfc2698 2 0 312500 312500 400 500 0'，test pass，close this defect -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 683] librte_pipeline build failures on CentOS 7
https://bugs.dpdk.org/show_bug.cgi?id=683 Bug ID: 683 Summary: librte_pipeline build failures on CentOS 7 Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: alia...@nvidia.com CC: cristian.dumitre...@intel.com Target Milestone: --- ``` $ meson --werror --buildtype=release build && ninja-build -C build [555/2604] Compiling C object lib/librte_pipeline.a.p/librte_pipeline_rte_swx_pipeline.c.o FAILED: lib/librte_pipeline.a.p/librte_pipeline_rte_swx_pipeline.c.o ccache cc -Ilib/librte_pipeline.a.p -Ilib -I../lib -Ilib/librte_pipeline -I../lib/librte_pipeline -I. -I.. -Iconfig -I../config -Ilib/librte_eal/include -I../lib/librte_eal/include -Ilib/librte_eal/linux/include -I../lib/librte_eal/linux/include -Ilib/librte_eal/x86/include -I../lib/librte_eal/x86/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_metrics -I../lib/librte_metrics -Ilib/librte_telemetry -I../lib/librte_telemetry -Ilib/librte_port -I../lib/librte_port -Ilib/librte_ethdev -I../lib/librte_ethdev -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter -I../lib/librte_meter -Ilib/librte_sched -I../lib/librte_sched -Ilib/librte_ip_frag -I../lib/librte_ip_frag -Ilib/librte_hash -I../lib/librte_hash -Ilib/librte_rcu -I../lib/librte_rcu -Ilib/librte_cryptodev -I../lib/librte_cryptodev -Ilib/librte_eventdev -I../lib/librte_eventdev -Ilib/librte_timer -I../lib/librte_timer -Ilib/librte_kni -I../lib/librte_kni -Ilib/librte_pci -I../lib/librte_pci -Ilib/librte_table -I../lib/librte_table -Ilib/librte_lpm -I../lib/librte_lpm -Ilib/librte_acl -I../lib/librte_acl -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O3 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -MD -MQ lib/librte_pipeline.a.p/librte_pipeline_rte_swx_pipeline.c.o -MF lib/librte_pipeline.a.p/librte_pipeline_rte_swx_pipeline.c.o.d -o lib/librte_pipeline.a.p/librte_pipeline_rte_swx_pipeline.c.o -c ../lib/librte_pipeline/rte_swx_pipeline.c ../lib/librte_pipeline/rte_swx_pipeline.c: In function 'instr_translate': ../lib/librte_pipeline/rte_swx_pipeline.c:4202:30: error: 'src_struct_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] instr->alu.src.struct_id = (uint8_t)src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:4181:26: note: 'src_struct_id' was declared here uint32_t dst_struct_id, src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:4216:29: error: 'dst_struct_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] instr->alu.dst.struct_id = (uint8_t)dst_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:4181:11: note: 'dst_struct_id' was declared here uint32_t dst_struct_id, src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3966:30: error: 'src_struct_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] instr->alu.src.struct_id = (uint8_t)src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3945:26: note: 'src_struct_id' was declared here uint32_t dst_struct_id, src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3980:29: error: 'dst_struct_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] instr->alu.dst.struct_id = (uint8_t)dst_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3945:11: note: 'dst_struct_id' was declared here uint32_t dst_struct_id, src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3913:30: error: 'src_struct_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] instr->alu.src.struct_id = (uint8_t)src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3892:26: note: 'src_struct_id' was declared here uint32_t dst_struct_id, src_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3927:29: error: 'dst_struct_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] instr->alu.dst.struct_id = (uint8_t)dst_struct_id; ^ ../lib/librte_pipeline/rte_swx_pipeline.c:3892:11: note
[dpdk-dev] [Bug 238] [tree-wide] enhance getopt_long usage
https://bugs.dpdk.org/show_bug.cgi?id=238 Thomas Monjalon (tho...@monjalon.net) changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Thomas Monjalon (tho...@monjalon.net) --- Resolved in http://git.dpdk.org/dpdk/commit/?id=270054edc9 -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 684] lcores_autotest consistently times out on ppc64el
https://bugs.dpdk.org/show_bug.cgi?id=684 Bug ID: 684 Summary: lcores_autotest consistently times out on ppc64el Product: DPDK Version: 20.11 Hardware: POWER OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: luca.bocca...@gmail.com Target Milestone: --- No useful error message with verbose logging, it just times out after 30s. Works fine on other architectures. Example: https://ci.debian.net/data/autopkgtest/unstable/ppc64el/d/dpdk/11755163/log.gz -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 685] ring_autotest consistently crashes with SIGBUS on armhf/armv7
https://bugs.dpdk.org/show_bug.cgi?id=685 Bug ID: 685 Summary: ring_autotest consistently crashes with SIGBUS on armhf/armv7 Product: DPDK Version: 20.11 Hardware: ARM OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: luca.bocca...@gmail.com Target Milestone: --- ring_autotest consistently crashes with SIGBUS when running on Debian armhf (armv7). This is running in a container, without root privileges, and without hugepages - as part of the fast suite. There is no useful log message with verbose debugging. Example: https://ci.debian.net/data/autopkgtest/testing/armhf/d/dpdk/11831498/log.gz -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 687] [dpdk-21.05] unit_tests_power/power_cpufreq: unit test failed
https://bugs.dpdk.org/show_bug.cgi?id=687
Bug ID: 687
Summary: [dpdk-21.05] unit_tests_power/power_cpufreq: unit test
failed
Product: DPDK
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: zhiminx.hu...@intel.com
Target Milestone: ---
ENV:
DPDK version:
dpdk-21.05-rc1: 1b593b9c832e9b284cc59665fe662242a3fc1daf
OS: CentOS Stream release 8/4.18.0-277.el8.x86_64
Compiler: gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC)
Hardware platform: Intel(R) Xeon(R) Gold 6139 CPU @ 2.30GHz
NIC hardware: Intel Corporation Ethernet Controller E810-C for QSFP [8086:1592]
CVL100Gx2
NIC firmware:
ice: 1.6.0_rc26_4_g2fb2c79e_dirty
firmware-version: 3.00 0x800071ff 1.2928.0
ICE OS Default Package version 1.3.26.0
Reproduced step:
1.
echo 2 > /sys/bus/pci/devices/\:81\:00.0/sriov_numvfs
2.
ip link set ens801f0 vf 0 trust on
3.
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1,2,3,4 -n 4 -a
:81:01.0,cap=dcf -a :81:01.1 --file-prefix=dpdk_11923_20210423100520
-- -i
4.
flow validate 0 ingress pattern eth / ipv6 / udp / gtpu / ipv6 src is 2001::1 /
tcp dst is 23 / end actions vf id 1 / end
output:
RTE>>power_cpufreq_autotest
POWER: Env isn't set yet!
POWER: Attempting to initialise ACPI cpufreq power management...
POWER: Initialized successfully for lcore 2 power management
POWER: Power management governor of lcore 2 has been set back to successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
POWER: Lcore id 128 can not exceeds 127
POWER: Initialized successfully for lcore 2 power management
POWER: Power management of lcore 2 is in use
POWER: Invalid lcore ID
POWER: NULL buffer supplied
POWER: Buffer size is not enough
POWER: Invalid lcore ID
POWER: Power management governor of lcore 2 has been set back to successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
Test Failed
expected output:
RTE>>power_cpufreq_autotest
POWER: Env isn't set yet!
POWER: Attempting to initialise ACPI cpufreq power management...
POWER: Initialized successfully for lcore 2 power management
POWER: Power management governor of lcore 2 has been set back to successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
POWER: Lcore id 128 can not exceeds 127
POWER: Initialized successfully for lcore 2 power management
POWER: Power management of lcore 2 is in use
POWER: Invalid lcore ID
POWER: NULL buffer supplied
POWER: Buffer size is not enough
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid frequency index 64, which should be less than 15
POWER: Invalid frequency index 15, which should be less than 15
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Invalid lcore ID
POWER: Power management governor of lcore 2 has been set back to successfully
POWER: Power management of lcore 2 has exited from 'userspace' mode and been
set back to the original
POWER: Power management of lcore 2 is not used
POWER: Lcore id 128 can not exceeds 127
Test OK
bad commit id: 606a234c6d3607c93a0426bdccdbf9aaa2b8e5f6
commit 606a234c6d3607c93a0426bdccdbf9aaa2b8e5f6 (refs/bisect/bad)
Author: Richael Zhuang
Date: Thu Apr 15 13:59:30 2021 +0800
test/power: round CPU frequency to check
The value in "/sys/.../cpuinfo_cur_freq" may not be exactly the
same as what was set. For example, if "240" is written to
"/sys/.../cpufreq/scaling_setspeed" to set the frequency, then the
value in "/sys/.../cpuinfo_cur_freq" may be "2401222". So need to
round the value.
Fixes: ed7c51a6a680 ("app/test: vm power management")
Cc: sta...@dpdk.org
Signed-off-by: Richael Zhuang
Reviewed-by: David Hunt
diff --git a/app/test/test_power_cpufreq.c b/app/test/test_power_cpufreq.c
index d47b3e0a1a..f753d24ac5 100644
— a/app/test/test_power_cpufreq.c
+++ b/app/test/test_power_cpufreq.c
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 688] [dpdk-21.05]metering_and_policing: Failed to add policy actions
https://bugs.dpdk.org/show_bug.cgi?id=688 Bug ID: 688 Summary: [dpdk-21.05]metering_and_policing: Failed to add policy actions Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: longfengx.li...@intel.com Target Milestone: --- Environment DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads version: 21.05-rc1:1b593b9c832e9b284cc59665fe662242a3fc1daf Other software versions: name/version for QEMU, OVS, etc. Repeat as required. OS: Fedora 33 5.9.10-200.fc33.x86_64 Compiler: gcc (GCC) 10.2.1 20201016 (Red Hat 10.2.1-6) Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz NIC hardware: XL710 for 40GbE QSFP+ Driver version: 2.15.9 NIC firmware: 8.30 0x8000a4ae 1.2926.0 Test Setup Steps to reproduce List the steps to reproduce the issue. 1. build dpdk # rm -rf x86_64-native-linuxapp-clang # CC=gcc meson --werror -Denable_kmods=True -Dlibdir=lib -Dc_args='-DRTE_EAL_IGB_UIO=1' --default-library=static x86_64-native-linuxapp-clang # ninja -C x86_64-native-linuxapp-clang 2. tester preparation # scp -v ./dep/meter_and_policy_config.tar.gz root@10.240.183.141:/tmp 3. DUT preparation # ./usertools/dpdk-devbind.py -b vfio-pci :84:00.0 :84:00.1 # tar xf /tmp/meter_and_policy_config.tar.gz -C /root/dpdk/drivers/net/softnic # cp /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*link LINK0 dev.*$/link LINK0 dev :84:00.0/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*link LINK1 dev.*$/link LINK1 dev :84:00.1/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*table action profile AP0.*$/table action profile AP0 ipv4 offset 270 fwd meter trtcm tc 1 stats pkts/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/^.*pipeline RX table match.*$/pipeline RX table match acl ipv4 offset 270 size 4K action AP0/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/thread 5 pipeline RX enable/thread 2 pipeline RX enable/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 # sed -i -e 's/thread 5 pipeline TX enable/thread 2 pipeline TX enable/g' /root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5 4. lanch app # x86_64-native-linuxapp-clang/app/dpdk-testpmd -l 0,1,2 -n 4 -a :84:00.0 -a :84:00.1 --file-prefix=dpdk_20927_20210425061914 -s 0x4 --vdev 'net_softnic0,firmware=/root/dpdk/drivers/net/softnic/meter_and_policing_firmware.cli-5' -- -i --rxq=2 --txq=2 --portmask=0x4 --disable-rss # add port meter profile trtcm_rfc2698 2 0 312500 312500 400 500 0 # add port meter policy 0 1 g_actions rss / end y_actions end Show the output from the previous commands. # #testpmd> add port meter profile trtcm_rfc2698 2 0 312500 312500 400 500 0 #testpmd> add port meter policy 0 1 g_actions rss / end y_actions end Bad arguments Expected Result Add policy actions successfully Regression Is this issue a regression: (Y/N) Y [root@localhost dpdk]# git show f29fa2c59b858dc725c3d8486eddb59797bbb6dc commit f29fa2c59b858dc725c3d8486eddb59797bbb6dc Author: Haifei Luo Date: Tue Apr 20 17:04:50 2021 +0300 app/testpmd: support policy actions per color Add the create/del policy CLIs to support actions per color. The CLIs are: Create: add port meter policy (port_id) (policy_id) g_actions (actions) y_actions (actions) r_actions (actions) Delete: del port meter policy (port_id) (policy_id) Examples: testpmd> add port meter policy 0 1 g_actions rss / end y_actions end r_actions drop / end testpmd> del port meter policy 0 1 Signed-off-by: Haifei Luo Acked-by: Matan Azrad Acked-by: Ajit Khaparde -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 238] [tree-wide] enhance getopt_long usage
https://bugs.dpdk.org/show_bug.cgi?id=238 David Marchand (david.march...@redhat.com) changed: What|Removed |Added Status|RESOLVED|CONFIRMED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 689] RTE bus list not populated causing EAL: failed to parse device "XX:XX.X" on CentOS 7
https://bugs.dpdk.org/show_bug.cgi?id=689 Bug ID: 689 Summary: RTE bus list not populated causing EAL: failed to parse device "XX:XX.X" on CentOS 7 Product: DPDK Version: 20.11 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: szymon.mikul...@nokia.com Target Milestone: --- On our CI setup we build DPDK on CentOS 7 There are no problems with compilation, we are able to compile it and our application. However when starting EAL: (rte_eal_init()) "./app -l 2-5 --file-prefix 04:00.0 -a 04:00.0 EAL: Detected 24 lcore(s) EAL: Detected 2 NUMA nodes EAL: Detected static linkage of DPDK EAL: failed to parse device "04:00.0" EAL: Unable to parse device '04:00.0' Cant init EAL" I've traced it back to PCI bus list being empty, none of the buses are registered for some reason. I am not sure how the buses are supposed to be registered with all the macro RTE_INIT_PRIO magic happening so I stopped there. The output from meson doesn't seem to be any different on the CentOS machine to more modern systems where everything works as expected Do you have any idea what might be happening and how to continue debugging? I've found that testpmd works ./dpdk-testpmd -l 2-5 --file-prefix 04:00.0 -a 04:00.0 -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 690] tap build failures on Fedora 35 with gcc 11
https://bugs.dpdk.org/show_bug.cgi?id=690 Bug ID: 690 Summary: tap build failures on Fedora 35 with gcc 11 Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: alia...@nvidia.com Target Milestone: --- """ $ meson --werror --buildtype=debugoptimized -Ddisable_drivers=net/ice build && ninja -C build ... ... [1803/2603] Compiling C object drivers/libtmp_rte_net_tap.a.p/net_tap_tap_flow.c.o FAILED: drivers/libtmp_rte_net_tap.a.p/net_tap_tap_flow.c.o ccache cc -Idrivers/libtmp_rte_net_tap.a.p -Idrivers -I../drivers -Idrivers/net/tap -I../drivers/net/tap -Idrivers/bus/vdev -I../drivers/bus/vdev -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include -I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/gso -I../lib/gso -Ilib/ethdev -I../lib/ethdev -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -Ilib/meter -I../lib/meter -Ilib/hash -I../lib/hash -Ilib/rcu -I../lib/rcu -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC -march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation -DTAP_MAX_QUEUES=16 -MD -MQ drivers/libtmp_rte_net_tap.a.p/net_tap_tap_flow.c.o -MF drivers/libtmp_rte_net_tap.a.p/net_tap_tap_flow.c.o.d -o drivers/libtmp_rte_net_tap.a.p/net_tap_tap_flow.c.o -c ../drivers/net/tap/tap_flow.c In file included from ../drivers/net/tap/tap_flow.c:13: In function 'rte_jhash_2hashes', inlined from 'rte_jhash' at ../lib/hash/rte_jhash.h:284:2, inlined from 'tap_flow_set_handle' at ../drivers/net/tap/tap_flow.c:1306:12, inlined from 'rss_enable' at ../drivers/net/tap/tap_flow.c:1909:3, inlined from 'priv_flow_process' at ../drivers/net/tap/tap_flow.c:1228:11: ../lib/hash/rte_jhash.h:238:9: error: 'flow' may be used uninitialized [-Werror=maybe-uninitialized] 238 | __rte_jhash_2hashes(key, length, pc, pb, 1); | ^~~ ../drivers/net/tap/tap_flow.c: In function 'priv_flow_process': ../lib/hash/rte_jhash.h:81:1: note: by argument 1 of type 'const void *' to '__rte_jhash_2hashes.constprop' declared here 81 | __rte_jhash_2hashes(const void *key, uint32_t length, uint32_t *pc, | ^~~ ../drivers/net/tap/tap_flow.c:1028:1: note: 'flow' declared here 1028 | priv_flow_process(struct pmd_internals *pmd, | ^ In file included from ../drivers/net/tap/tap_flow.c:13: In function 'rte_jhash_2hashes', inlined from 'rte_jhash' at ../lib/hash/rte_jhash.h:284:2, inlined from 'tap_flow_set_handle' at ../drivers/net/tap/tap_flow.c:1306:12, inlined from 'tap_flow_create' at ../drivers/net/tap/tap_flow.c:1393:2: ../lib/hash/rte_jhash.h:238:9: error: 'flow' may be used uninitialized [-Werror=maybe-uninitialized] 238 | __rte_jhash_2hashes(key, length, pc, pb, 1); | ^~~ ../drivers/net/tap/tap_flow.c: In function 'tap_flow_create': ../lib/hash/rte_jhash.h:81:1: note: by argument 1 of type 'const void *' to '__rte_jhash_2hashes.constprop' declared here 81 | __rte_jhash_2hashes(const void *key, uint32_t length, uint32_t *pc, | ^~~ ../drivers/net/tap/tap_flow.c:1354:1: note: 'flow' declared here 1354 | tap_flow_create(struct rte_eth_dev *dev, | ^~~ In file included from ../drivers/net/tap/tap_flow.c:13: In function 'rte_jhash_2hashes', inlined from 'rte_jhash' at ../lib/hash/rte_jhash.h:284:2, inlined from 'tap_flow_set_handle' at ../drivers/net/tap/tap_flow.c:1306:12, inlined from 'tap_flow_create' at ../drivers/net/tap/tap_flow.c:1432:3: ../lib/hash/rte_jhash.h:238:9: error: 'flow' may be used uninitialized [-Werror=maybe-uninitialized] 238 | __rte_jhash_2hashes(key, length, pc, pb, 1); | ^~~ ../drivers/net/tap/tap_flow.c: In function 'tap_flow_create': ../lib/hash/rte_jhash.h:81:1: note: by argument 1 of type 'const void *' to '__rte_jhash_2hashes.constprop' declared here 81 | __rte_jhash_2hashes(const void *key, uint32_t length, uint32_t *pc, | ^~~
[dpdk-dev] [Bug 691] test-pmd build failure on Fedora 35 with gcc 11
https://bugs.dpdk.org/show_bug.cgi?id=691
Bug ID: 691
Summary: test-pmd build failure on Fedora 35 with gcc 11
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: alia...@nvidia.com
Target Milestone: ---
"""
$ meson --werror --buildtype=debugoptimized -Ddisable_drivers=net/ice,net/tap
build && ninja -C build
...
...
[2584/2587] Compiling C object app/dpdk-testpmd.p/test-pmd_config.c.o
FAILED: app/dpdk-testpmd.p/test-pmd_config.c.o
ccache cc -Iapp/dpdk-testpmd.p -Iapp -I../app -Ilib/ethdev -I../lib/ethdev -I.
-I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
-Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
-I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
-Ilib/meter -I../lib/meter -Ilib/gro -I../lib/gro -Ilib/gso -I../lib/gso
-Ilib/cmdline -I../lib/cmdline -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Ilib/bitratestats
-I../lib/bitratestats -Ilib/pdump -I../lib/pdump -Ilib/latencystats
-I../lib/latencystats -Idrivers/crypto/scheduler -I../drivers/crypto/scheduler
-Ilib/cryptodev -I../lib/cryptodev -Ilib/rcu -I../lib/rcu -Idrivers/bus/vdev
-I../drivers/bus/vdev -Ilib/reorder -I../lib/reorder -Idrivers/net/bonding
-I../drivers/net/bonding -Ilib/sched -I../lib/sched -Ilib/ip_frag
-I../lib/ip_frag -Ilib/hash -I../lib/hash -Idrivers/net/bnxt
-I../drivers/net/bnxt -I../drivers/net/bnxt/tf_ulp
-I../drivers/net/bnxt/tf_core -Idrivers/net/i40e -I../drivers/net/i40e
-Idrivers/net/i40e/base -I../drivers/net/i40e/base -Idrivers/net/ixgbe
-I../drivers/net/ixgbe -Idrivers/net/ixgbe/base -I../drivers/net/ixgbe/base
-Ilib/security -I../lib/security -Idrivers/bus/dpaa -I../drivers/bus/dpaa
-I../drivers/bus/dpaa/include -I../drivers/bus/dpaa/base/qbman
-Idrivers/common/dpaax -I../drivers/common/dpaax
-I../drivers/common/dpaax/caamflib -Ilib/eventdev -I../lib/eventdev -Ilib/timer
-I../lib/timer -Idrivers/mempool/dpaa -I../drivers/mempool/dpaa
-Idrivers/net/dpaa -I../drivers/net/dpaa -Ilib/bpf -I../lib/bpf
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE
-march=native -DALLOW_EXPERIMENTAL_API -Wno-deprecated-declarations -MD -MQ
app/dpdk-testpmd.p/test-pmd_config.c.o -MF
app/dpdk-testpmd.p/test-pmd_config.c.o.d -o
app/dpdk-testpmd.p/test-pmd_config.c.o -c ../app/test-pmd/config.c
../app/test-pmd/config.c: In function 'port_action_handle_query':
../app/test-pmd/config.c:1680:51: error: array subscript 'struct
rte_flow_action_conntrack[0]' is partly outside array bounds of 'uint64_t[1]'
{aka 'long unsigned int[1]'} [-Werror=array-bounds]
1680 |ct->last_window, ct->last_end);
| ^~
../app/test-pmd/config.c:1621:18: note: while referencing 'default_data'
1621 | uint64_t default_data;
| ^~~~
../app/test-pmd/config.c:1680:34: error: array subscript 'struct
rte_flow_action_conntrack[0]' is partly outside array bounds of 'uint64_t[1]'
{aka 'long unsigned int[1]'} [-Werror=array-bounds]
1680 |ct->last_window, ct->last_end);
| ^~
../app/test-pmd/config.c:1621:18: note: while referencing 'default_data'
1621 | uint64_t default_data;
| ^~~~
../app/test-pmd/config.c:1679:64: error: array subscript 'struct
rte_flow_action_conntrack[0]' is partly outside array bounds of 'uint64_t[1]'
{aka 'long unsigned int[1]'} [-Werror=array-bounds]
1679 |ct->last_index, ct->last_seq,
ct->last_ack,
|^~
../app/test-pmd/config.c:1621:18: note: while referencing 'default_data'
1621 | uint64_t default_data;
| ^~~~
../app/test-pmd/config.c:1679:50: error: array subscript 'struct
rte_flow_action_conntrack[0]' is partly outside array bounds of 'uint64_t[1]'
{aka 'long unsigned int[1]'} [-Werror=array-bounds]
1679 |ct->last_index, ct->last_seq,
ct->last_ack,
|
[dpdk-dev] [Bug 692] bnx2x build fail on Fedora 34 with gcc 11
https://bugs.dpdk.org/show_bug.cgi?id=692
Bug ID: 692
Summary: bnx2x build fail on Fedora 34 with gcc 11
Product: DPDK
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: kevu...@gmail.com
Target Milestone: ---
[kevin@fedora dpdk]$ cat /etc/redhat-release
Fedora release 34 (Thirty Four)
[kevin@fedora dpdk]$ uname -a
Linux fedora 5.11.15-300.fc34.x86_64 #1 SMP Fri Apr 16 13:41:48 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
[kevin@fedora dpdk]$ gcc --version
gcc (GCC) 11.0.1 20210324 (Red Hat 11.0.1-0)
[kevin@fedora dpdk]$ ./devtools/test-meson-builds.sh
ninja: Entering directory `./build-gcc-static'
[842/2503] Compiling C object
drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x_rxtx.c.o
FAILED: drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x_rxtx.c.o
gcc -Idrivers/libtmp_rte_net_bnx2x.a.p -Idrivers -I../drivers
-Idrivers/net/bnx2x -I../drivers/net/bnx2x -Ilib/ethdev -I../lib/ethdev -I.
-I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
-Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
-I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
-Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
-I../drivers/bus/vdev -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes
-Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC
-march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -DZLIB_CONST -MD -MQ
drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x_rxtx.c.o -MF
drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x_rxtx.c.o.d -o
drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x_rxtx.c.o -c
../drivers/net/bnx2x/bnx2x_rxtx.c
In file included from ../drivers/net/bnx2x/bnx2x_rxtx.c:8:
../drivers/net/bnx2x/bnx2x_rxtx.c: In function ‘bnx2x_upd_rx_prod_fast’:
../drivers/net/bnx2x/bnx2x.h:1528:35: error: ‘rx_prods’ is used uninitialized
[-Werror=uninitialized]
1528 | #define REG_WR32(sc, offset, val) bnx2x_reg_write32(sc, (offset), val)
| ^~~~
../drivers/net/bnx2x/bnx2x.h:1531:33: note: in expansion of macro ‘REG_WR32’
1531 | #define REG_WR(sc, offset, val) REG_WR32(sc, offset, val)
| ^~~~
../drivers/net/bnx2x/bnx2x_rxtx.c:331:9: note: in expansion of macro ‘REG_WR’
331 | REG_WR(sc, fp->ustorm_rx_prods_offset, val[0]);
| ^~
../drivers/net/bnx2x/bnx2x_rxtx.c:324:40: note: ‘rx_prods’ declared here
324 | struct ustorm_eth_rx_producers rx_prods = { 0 };
|^~~~
cc1: all warnings being treated as errors
[846/2503] Compiling C object
drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x.c.o
FAILED: drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x.c.o
gcc -Idrivers/libtmp_rte_net_bnx2x.a.p -Idrivers -I../drivers
-Idrivers/net/bnx2x -I../drivers/net/bnx2x -Ilib/ethdev -I../lib/ethdev -I.
-I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include
-Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/x86/include
-I../lib/eal/x86/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal
-I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics
-Ilib/telemetry -I../lib/telemetry -Ilib/net -I../lib/net -Ilib/mbuf
-I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring
-Ilib/meter -I../lib/meter -Idrivers/bus/pci -I../drivers/bus/pci
-I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/bus/vdev
-I../drivers/bus/vdev -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
-Wall -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual
-Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs
-Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes
-Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned
-Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -fPIC
-march=native -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API
-Wno-format-truncation -DZLIB_CONST -MD -MQ
drivers/libtmp_rte_net_bnx2x.a.p/net_bnx2x_bnx2x
[dpdk-dev] [Bug 693] [dpdk-21.05] shutdown_api/change_linkspeed: port config speed is invalid
https://bugs.dpdk.org/show_bug.cgi?id=693
Bug ID: 693
Summary: [dpdk-21.05] shutdown_api/change_linkspeed: port
config speed is invalid
Product: DPDK
Version: unspecified
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: testpmd
Assignee: dev@dpdk.org
Reporter: linglix.c...@intel.com
Target Milestone: ---
Environment
DPDK version: 21.05-rc1: 1b593b9c832e9b284cc59665fe662242a3fc1daf
OS: CentOS Stream release 8/4.18.0-277.el8.x86_64
Compiler: gcc (GCC) 8.4.1
Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz.
NIC hardware: Ethernet Controller I225-LM 15f2
driver：igc 0.0.1-k（foxville）
Reproduce Step:
1.bind port on vfio-pci
#usertools/dpdk-devbind.py --force --bind=vfio-pci :81:00.0
2. launch test-pmd
#x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 1,2 -n 4 -a :81:00.0
--file-prefix=dpdk_23328_20210427094637 -- -i --portmask=0x1
--port-topology=loop
3.tester: ethtool ens803
Settings for ens803:
Supported ports: [ ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
4.testpmd> set promisc all off
testpmd> port stop all
testpmd>port config 0 speed 100 duplex full
testpmd>port start all
5.testpmd>show port info 0
* Infos for port 0 *
MAC address: 00:A0:C9:00:00:00
Device name: :81:00.0
Driver name: net_igc
Firmware-version: 1.3, 0x80c9
Devargs:
Connect to socket: 1
memory allocation on the socket: 1
Link status: up
Link speed: 2.5 Gbps
Link duplex: full-duplex
Expected Result: Link speed should be 100 Mbps.
Regression
Is this issue a regression: (Y/N) Y
Version the regression was introduced: Specify git id if known.
First bad commit:
commit 312312e928c71cb6b45aeaab2b421d059897dd07
Author: Huisong Li
Date: Wed Apr 14 11:02:05 2021 +0800
app/testpmd: fix bitmap of link speeds when force speed
Currently, when the user sets force link speed through 'link_speeds',
bit(0) of 'link_speeds' is not set to 1(ETH_LINK_SPEED_FIXED),
which conflicts with the definition.
Fixes: 88fbedcd5e5a ("app/testpmd: move speed and duplex parsing in a
function")
Cc: sta...@dpdk.org
Signed-off-by: Huisong Li
Signed-off-by: Min Hu (Connor)
Acked-by: Ferruh Yigit
Acked-by: Ajit Khaparde
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 689] RTE bus list not populated causing EAL: failed to parse device "XX:XX.X" on CentOS 7 with static linkage
https://bugs.dpdk.org/show_bug.cgi?id=689 Thomas Monjalon (tho...@monjalon.net) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Thomas Monjalon (tho...@monjalon.net) --- I've closed it, thanks. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 694] build vm_power_manager using Make
https://bugs.dpdk.org/show_bug.cgi?id=694 Bug ID: 694 Summary: build vm_power_manager using Make Product: DPDK Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: brian.ry...@intel.com Target Milestone: --- STEPS TO REPRODUCE: git DPDK, install DPDK , install libvirt , go to dpdk/examples/vm_power_manager and make. EXPECTED RESULT: vm_power_manager builds ACTUAL RESULT: Makefile:46: *** vm_power_manager requires libvirt >= 0.9.3. Stop. COMMENT: libvirtd (libvirt) 3.2.1 installed DATE: 2021-04-28 DPDK VERSION: 21.05.0-rc1 -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 695] ipsec-secgw packet validation test fail
https://bugs.dpdk.org/show_bug.cgi?id=695 Bug ID: 695 Summary: ipsec-secgw packet validation test fail Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: vladimir.medved...@intel.com Target Milestone: --- ipsec-secgw packet validation test fails: ./run_test.sh -p fails with: Running test case: trs_ipv6optstest_inb_ipv6_frag (__main__.TestTransportWithIPv6Ext) ... ERRORtest_inb_ipv6_noopt (__main__.TestTransportWithIPv6Ext) ... oktest_inb_ipv6_opt (__main__.TestTransportWithIPv6Ext) ... ERRORtest_outb_ipv6_noopt (__main__.TestTransportWithIPv6Ext) ... oktest_outb_ipv6_opt (__main__.TestTransportWithIPv6Ext) ... ok ... FAILED (errors=2) Test case trs_ipv6opts failed! pkttests finished with status 1 ERROR pkttests FAILED Problematic commit-id commit 9a1cc8f1ed746ef9cac7846afaa2667f9abd9427 (refs/bisect/bad) Author: Tejasree Kondoj Date: Thu Apr 15 12:52:04 2021 +0530 examples/ipsec-secgw: support UDP encapsulation Adding lookaside IPsec UDP encapsulation support for NAT traversal. Application has to add udp-encap option to sa config file to enable UDP encapsulation on the SA. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 697] build failure in event/cnxk when cross-compiling with gcc 7.1.1
https://bugs.dpdk.org/show_bug.cgi?id=697
Bug ID: 697
Summary: build failure in event/cnxk when cross-compiling with
gcc 7.1.1
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: alia...@nvidia.com
Target Milestone: ---
"""
$ meson --werror --buildtype=debugoptimized --cross-file
config/arm/arm64_armv8_linux_gcc build && ninja -C build
...
...
The Meson build system
Version: 0.55.3
Source dir: /tmp/dpdk
Build dir: /tmp/build-aarch64-gcc
Build type: cross build
Program cat found: YES
Project name: DPDK
Project version: 21.05.0-rc2
C compiler for the build machine: ccache cc (gcc 10.3.1 "cc (GCC) 10.3.1
20210422 (Red Hat 10.3.1-1)")
C linker for the build machine: cc ld.bfd 2.35-18
C compiler for the host machine: aarch64-linux-gnu-gcc (gcc 7.1.1
"aarch64-linux-gnu-gcc (Linaro GCC 7.1-2017.08) 7.1.1 20170707")
C linker for the host machine: aarch64-linux-gnu-gcc ld.bfd 2.28.2.20170706
...
...
[2106/2604] Compiling C object
drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cn10k_worker.c.o
FAILED: drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cn10k_worker.c.o
aarch64-linux-gnu-gcc -Idrivers/libtmp_rte_event_cnxk.a.p -Idrivers
-I../dpdk/drivers -Idrivers/event/cnxk -I../dpdk/drivers/event/cnxk
-Ilib/eventdev -I../dpdk/lib/eventdev -I. -I../dpdk -Iconfig -I../dpdk/config
-Ilib/eal/include -I../dpdk/lib/eal/include -Ilib/eal/linux/include
-I../dpdk/lib/eal/linux/include -Ilib/eal/arm/include
-I../dpdk/lib/eal/arm/include -Ilib/eal/common -I../dpdk/lib/eal/common
-Ilib/eal -I../dpdk/lib/eal -Ilib/kvargs -I../dpdk/lib/kvargs -Ilib/metrics
-I../dpdk/lib/metrics -Ilib/telemetry -I../dpdk/lib/telemetry -Ilib/ring
-I../dpdk/lib/ring -Ilib/ethdev -I../dpdk/lib/ethdev -Ilib/net
-I../dpdk/lib/net -Ilib/mbuf -I../dpdk/lib/mbuf -Ilib/mempool
-I../dpdk/lib/mempool -Ilib/meter -I../dpdk/lib/meter -Ilib/hash
-I../dpdk/lib/hash -Ilib/rcu -I../dpdk/lib/rcu -Ilib/timer -I../dpdk/lib/timer
-Ilib/cryptodev -I../dpdk/lib/cryptodev -Idrivers/bus/pci
-I../dpdk/drivers/bus/pci -I../dpdk/drivers/bus/pci/linux -Ilib/pci
-I../dpdk/lib/pci -Idrivers/common/cnxk -I../dpdk/drivers/common/cnxk
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat
-Wformat-nonliteral -Wformat-security -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith
-Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings
-Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8-a+crc
-DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -Wno-format-truncation -MD -MQ
drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cn10k_worker.c.o -MF
drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cn10k_worker.c.o.d -o
drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cn10k_worker.c.o -c
../dpdk/drivers/event/cnxk/cn10k_worker.c
{standard input}: Assembler messages:
{standard input}:620: Error: reg pair must start from even reg at operand 1 --
`caspl x5,x6,x5,x6,[x4]'
[2139/2604] Compiling C object
drivers/libtmp_rte_event_octeontx2.a.p/event_octeontx2_otx2_worker.c.o
ninja: build stopped: subcommand failed.
"""
os: Fedora 33
cross compiler: gcc 7.1.1 "aarch64-linux-gnu-gcc (Linaro GCC 7.1-2017.08) 7.1.1
20170707"
https://releases.linaro.org/components/toolchain/binaries/7.1-2017.08/aarch64-linux-gnu/gcc-linaro-7.1.1-2017.08-x86_64_aarch64-linux-gnu.tar.xz
meson: 0.55.3
ninja: 1.10.2
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 739] Building DPDK with gcc 10.2.1 Generates Multiple Warning Messages
https://bugs.dpdk.org/show_bug.cgi?id=739
Bug ID: 739
Summary: Building DPDK with gcc 10.2.1 Generates Multiple
Warning Messages
Product: DPDK
Version: unspecified
Hardware: POWER
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: other
Assignee: dev@dpdk.org
Reporter: d...@linux.vnet.ibm.com
Target Milestone: ---
Created attachment 162
--> https://bugs.dpdk.org/attachment.cgi?id=162&action=edit
Full Build Output Including Warnings
Building DPDK 21.08-rc0 with gcc 10.2.1 on RHEL 8.3 generates multiple
warnings, though the final executables appear to work correctly. Examples of
such warnings include:
[115/2415] Compiling C object
'lib/76b5a35@@rte_eal@sta/eal_common_eal_common_trace_utils.c.o'.
../lib/eal/common/eal_common_trace_utils.c: In function
‘trace_epoch_time_save’:
../lib/eal/common/eal_common_trace_utils.c:284:22: note: the layout of
aggregates containing vectors with 8-byte alignment has changed in GCC 5
284 | trace->uptime_ticks = avg;
| ^
[225/2415] Compiling C object 'lib/76b5a35@@rte_acl@sta/acl_acl_gen.c.o'.
../lib/acl/acl_gen.c: In function ‘acl_count_trie_types.constprop’:
../lib/acl/acl_gen.c:220:1: note: the layout of aggregates containing vectors
with 4-byte alignment has changed in GCC 5
220 | acl_count_trie_types(struct acl_node_counters *counts,
| ^~~~
...
[320/2415] Compiling C object 'lib/76b5a35@@rte_hash@sta/hash_rte_thash.c.o'.
In file included from ../lib/mempool/rte_mempool.h:51,
from ../lib/mbuf/rte_mbuf.h:38,
from ../lib/net/rte_ip.h:31,
from ../lib/hash/rte_thash.h:29,
from ../lib/hash/rte_thash.c:5:
In function ‘rte_memcpy_func’,
inlined from ‘rte_thash_init_ctx’ at ../lib/hash/rte_thash.c:232:3:
../lib/eal/ppc/include/rte_memcpy.h:50:2: warning: writing 16 bytes into a
region of size 0 [-Wstringop-overflow=]
50 | vec_vsx_st(vec_vsx_ld(0, src), 0, dst);
| ^~
...
[323/2415] Compiling C object 'lib/76b5a35@@rte_lpm@sta/lpm_rte_lpm.c.o'.
../lib/lpm/rte_lpm.c: In function ‘rte_lpm_create’:
../lib/lpm/rte_lpm.c:240:19: note: the layout of aggregates containing vectors
with 8-byte alignment has changed in GCC 5
240 | i_lpm->max_rules = config->max_rules;
| ~^~~
[328/2415] Compiling C object
'drivers/a715181@@tmp_rte_net_bnxt@sta/net_bnxt_tf_ulp_bnxt_ulp_flow.c.o'.
../drivers/net/bnxt/tf_ulp/bnxt_ulp_flow.c: In function
‘bnxt_ulp_init_mapper_params’:
../drivers/net/bnxt/tf_ulp/bnxt_ulp_flow.c:78:1: note: the layout of aggregates
containing vectors with 8-byte alignment has changed in GCC 5
78 | bnxt_ulp_init_mapper_params(struct bnxt_ulp_mapper_create_parms
*mapper_cparms,
| ^~~
...
[1153/2415] Compiling C object
'drivers/a715181@@tmp_rte_net_ena@sta/net_ena_ena_ethdev.c.o'.
In file included from ../lib/net/rte_ether.h:21,
from ../drivers/net/ena/ena_ethdev.c:7:
../drivers/net/ena/ena_ethdev.c: In function ‘ena_rss_key_fill’:
../lib/eal/ppc/include/rte_memcpy.h:53:2: warning: array subscript 3 is outside
array bounds of ‘uint8_t[40]’ {aka ‘unsigned char[40]’} [-Warray-bounds]
53 | vec_vsx_st(vec_vsx_ld(48, src), 48, dst);
| ^~
../drivers/net/ena/ena_ethdev.c:277:17: note: while referencing ‘default_key’
277 | static uint8_t default_key[ENA_HASH_KEY_SIZE];
| ^~~
In file included from ../lib/net/rte_ether.h:21,
from ../drivers/net/ena/ena_ethdev.c:7:
../lib/eal/ppc/include/rte_memcpy.h:53:2: warning: array subscript [3, 7] is
outside array bounds of ‘uint8_t[40]’ {aka ‘unsigned char[40]’}
[-Warray-bounds]
53 | vec_vsx_st(vec_vsx_ld(48, src), 48, dst);
| ^~
../drivers/net/ena/ena_ethdev.c:277:17: note: while referencing ‘default_key’
277 | static uint8_t default_key[ENA_HASH_KEY_SIZE];
| ^~~
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 740] event/cnxk/cnxk_tim_worker build failures on Ubuntu 20.04 cross-compile with clang 10
https://bugs.dpdk.org/show_bug.cgi?id=740 Bug ID: 740 Summary: event/cnxk/cnxk_tim_worker build failures on Ubuntu 20.04 cross-compile with clang 10 Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: b...@iol.unh.edu Target Milestone: --- Cross-compiling DPDK on Ubuntu 20.04 with clang 10.0.0-4ubuntu1 on latest main (46c451d905e8e27787a0471ecc1d31a4cde25a9e) $ CC_FOR_BUILD=clang meson build --werror --cross-file config/arm/arm64_armv8_linux_clang_ubuntu1804 -Dexamples=all --default-library shared The Meson build system Version: 0.58.0 Found ninja-1.10.0 at /usr/bin/ninja [1901/2540] Compiling C object drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cnxk_tim_worker.c.o FAILED: drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cnxk_tim_worker.c.o clang -Idrivers/libtmp_rte_event_cnxk.a.p -Idrivers -I../drivers -Idrivers/event/cnxk -I../drivers/event/cnxk -Ilib/eventdev -I../lib/eventdev -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/arm/include -I../lib/eal/arm/include -Ilib/eal/common -I../lib/eal/common -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/metrics -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/ring -I../lib/ring -Ilib/ethdev -I../lib/ethdev -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/meter -I../lib/meter -Ilib/hash -I../lib/hash -Ilib/rcu -I../lib/rcu -Ilib/timer -I../lib/timer -Ilib/cryptodev -I../lib/cryptodev -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/linux -Ilib/pci -I../lib/pci -Idrivers/common/cnxk -I../drivers/common/cnxk -fcolor-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O3 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-missing-field-initializers -D_GNU_SOURCE -target aarch64-linux-gnu --sysroot /usr/aarch64-linux-gnu -fPIC -march=armv8-a+crc -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -DRTE_LOG_DEFAULT_LOGTYPE=pmd.event.cnxk -MD -MQ drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cnxk_tim_worker.c.o -MF drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cnxk_tim_worker.c.o.d -o drivers/libtmp_rte_event_cnxk.a.p/event_cnxk_cnxk_tim_worker.c.o -c ../drivers/event/cnxk/cnxk_tim_worker.c In file included from ../drivers/event/cnxk/cnxk_tim_worker.c:6: ../drivers/event/cnxk/cnxk_tim_worker.h:372:23: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths] : [rem] "=&r"(rem) ^ ../drivers/event/cnxk/cnxk_tim_worker.h:365:17: note: use constraint modifier "w" " ldxr %[rem], [%[crem]] \n" ^~ %w[rem] ../drivers/event/cnxk/cnxk_tim_worker.h:372:23: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths] : [rem] "=&r"(rem) ^ ../drivers/event/cnxk/cnxk_tim_worker.h:366:16: note: use constraint modifier "w" " tbz %[rem], 63, dne%= \n" ^~ %w[rem] ../drivers/event/cnxk/cnxk_tim_worker.h:372:23: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths] : [rem] "=&r"(rem) ^ ../drivers/event/cnxk/cnxk_tim_worker.h:369:17: note: use constraint modifier "w" " ldxr %[rem], [%[crem]] \n" ^~ %w[rem] ../drivers/event/cnxk/cnxk_tim_worker.h:372:23: error: value size does not match register size specified by the constraint and modifier [-Werror,-Wasm-operand-widths] : [rem] "=&r"(rem) ^ ../drivers/event/cnxk/cnxk_tim_worker.h:370:17: note: use constraint modifier "w" " tbnz %[rem], 63, rty%= \n" ^~ %w[rem] 4 errors generated. [1918/2540] Compiling C object drivers/libtmp_rte_event_octeontx2.a.p/event_octeontx2_otx2_worker.c.o --
[dpdk-dev] [Bug 741] [dpdk-21.05]vhost relaunch meet Segmentation fault issue when virtio queues larger than vhost queues
https://bugs.dpdk.org/show_bug.cgi?id=741
Bug ID: 741
Summary: [dpdk-21.05]vhost relaunch meet Segmentation fault
issue when virtio queues larger than vhost queues
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: vhost/virtio
Assignee: dev@dpdk.org
Reporter: weix.l...@intel.com
Target Milestone: ---
Issue discription：
vhost relaunch meet segment fault issue from when virtio queues larger than
vhost queues.
Test Environment:
DPDK version: DPDK v21.05
OS: Linux 5.4
Compiler: gcc 9.3
CPU: 8280m
The reproduce step is :
1. launch two vhost ports :
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -n 4 -l 2-4 --file-prefix=vhost
--vdev 'net_vhost0,iface=/tmp/s0,client=1,queues=1' --vdev
'net_vhost1,iface=/tmp/s1,client=1,queues=1' -- -i --nb-cores=1 --txd=1024
--rxd=1024
testpmd>start
2. launch one virtio-user:
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -n 4 -l 5-6 --no-pci
--file-prefix=virtio0 \
--vdev=net_virtio_user0,mac=00:01:02:03:04:05,path=/tmp/s0,server=1,mrg_rxbuf=0,in_order=0,queues=1
\
-- -i --tx-offloads=0x0 --enable-hw-vlan-strip --nb-cores=1 --txd=1024
--rxd=1024
testpmd>start
3. launch another virtio-user with queue number=8:
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -n 4 -l 7-8 --no-pci
--file-prefix=virtio1 \
--vdev=net_virtio_user1,mac=00:01:02:03:04:55,path=/tmp/s1,server=1,mrg_rxbuf=0,in_order=0,queues=8
\
-- -i --tx-offloads=0x0 --enable-hw-vlan-strip --nb-cores=1 --txd=1024
--rxd=1024
testpmd>start tx_first 32
4. relaunch two vhost ports :
./x86_64-native-linuxapp-gcc/app/dpdk-testpmd -n 4 -l 2-4 --file-prefix=vhost
--vdev 'net_vhost0,iface=/tmp/s0,client=1,queues=1' --vdev
'net_vhost1,iface=/tmp/s1,client=1,queues=1' -- -i --nb-cores=1 --txd=1024
--rxd=1024
Result:
Checking link statuses...
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 0
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 0
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 1
VHOST_CONFIG: read message VHOST_USER_SET_VRING_ENABLE
VHOST_CONFIG: set queue enable: 0 to qp idx: 1
VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
VHOST_CONFIG: vring base idx:0 file:0
VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
VHOST_CONFIG: vring base idx:0 file:0
VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
VHOST_CONFIG: vring base idx:1 file:0
VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
VHOST_CONFIG: vring base idx:1 file:0
VHOST_CONFIG: read message VHOST_USER_GET_FEATURES
VHOST_CONFIG: read message VHOST_USER_GET_VRING_BASE
Segmentation fault
Expected Result:
vhost port can relaunch success and 1 queue can wok.
Is this issue a regression: Y
Version the regression was introduced: Specify git id if known.
root@dpdk:~/dpdk# git bisect bad
commit 7804bbd13aa583e3a28b08557f7a98fcbe7fc8a8 (HEAD -> main)
Author: Maxime Coquelin
Date: Fri Nov 6 15:47:44 2020 +0100
vhost: fix virtqueue initialization
This patches fixes virtqueue initialization issue causing
segfault or file descriptor being closed unexpectedly.
The wrong index was passed to init_vring_queue() by
alloc_vring_queue() when a hole in the virtqueue array was
met.
Fixes: 8acd7c213353 ("vhost: fix virtqueues metadata allocation")
Cc: sta...@dpdk.org
Reported-by: Yu Jiang
Signed-off-by: Maxime Coquelin
Reviewed-by: David Marchand
Tested-by: Yu Jiang
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 742] intermittent func_reentrancy_autotest failures
https://bugs.dpdk.org/show_bug.cgi?id=742 Bug ID: 742 Summary: intermittent func_reentrancy_autotest failures Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: acon...@bytheb.org Target Milestone: --- In the UNH IOL we see intermittent failures from the func_reentrancy_autotest which happen regardless of platform. Sometimes the report looks like: (from https://lab.dpdk.org/results/dashboard/patchsets/17321/) 27/93 DPDK:fast-tests / func_reentrancy_autotest FAIL 3.08s (exit status 255 or signal 127 SIGinvalid) --- command --- 07:03:58 DPDK_TEST='func_reentrancy_autotest' /home-local/jenkins-local/jenkins-agent/workspace/Arm-gigabyte-Unit-Test-DPDK/dpdk/build/app/test/dpdk-test -l 0-63 --file-prefix=func_reentrancy_autotest --- stdout --- RTE>>func_reentrancy_autotest Too many lcores, some cores will be disabled Func-ReEnt CASE 0: eal init once PASS Func-ReEnt CASE 1: ring create/lookup PASS Func-ReEnt CASE 2: mempool create/lookup FAIL Test Failed RTE>> Sometimes it looks like: --- command --- 12:35:49 DPDK_TEST='func_reentrancy_autotest' /home-local/jenkins-local/jenkins-agent/workspace/Generic-Unit-Test-DPDK/dpdk/build/app/test/dpdk-test -l 0-15 --file-prefix=func_reentrancy_autotest --- stdout --- RTE>>func_reentrancy_autotest --- stderr --- EAL: Detected 16 lcore(s) EAL: Detected 2 NUMA nodes EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/func_reentrancy_autotest/mp_socket EAL: Selected IOVA mode 'PA' EAL: No available 1048576 kB hugepages reported EAL: VFIO support initialized EAL: Invalid NUMA socket, default to 0 APP: HPET is not enabled, using TSC as default timer EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: already called initialization. EAL: FATAL: already called initialization. EAL: FATAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: FATAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. EAL: already called initialization. RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory RING: Cannot reserve memory --- Probably there is some issue allocating memory but not enough in
[dpdk-dev] [Bug 743] Building DPDK with gcc 11.1.1 Generates Multiple Warning Messages in the i40e PMD
https://bugs.dpdk.org/show_bug.cgi?id=743 Bug ID: 743 Summary: Building DPDK with gcc 11.1.1 Generates Multiple Warning Messages in the i40e PMD Product: DPDK Version: unspecified Hardware: POWER OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: d...@linux.vnet.ibm.com Target Milestone: --- Using Fedora 34 container on ppc64le host with gcc 11. Running the same test in a Fedora 34 VM on x86 does not produce an error. [root@ee54008db177 dpdk]# gcc --version gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Warning errors generated when building the i40e PMD, even after proposed fixes for bug 739 are applied. [root@ee54008db177 dpdk]# ninja -C build ninja: Entering directory `build' [1270/2422] Compiling C object drivers/libtmp_rte_net_i40e.a.p/net_i40e_i40e_flow.c.o In function 'i40e_flow_parse_fdir_pattern', inlined from 'i40e_flow_parse_fdir_filter' at ../drivers/net/i40e/i40e_flow.c:3274:8: ../drivers/net/i40e/i40e_flow.c:3052:69: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 3052 | filter->input.flow_ext.flexbytes[j] = | ^ 3053 | raw_spec->pattern[i]; | In file included from ../drivers/net/i40e/i40e_flow.c:25: ../drivers/net/i40e/i40e_flow.c: In function 'i40e_flow_parse_fdir_filter': ../drivers/net/i40e/i40e_ethdev.h:628:17: note: at offset 16 into destination object 'flexbytes' of size 16 628 | uint8_t flexbytes[RTE_ETH_FDIR_MAX_FLEXLEN]; | ^ In function 'i40e_flow_parse_fdir_pattern', inlined from 'i40e_flow_parse_fdir_filter' at ../drivers/net/i40e/i40e_flow.c:3274:8: ../drivers/net/i40e/i40e_flow.c:3054:69: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 3054 | filter->input.flow_ext.flex_mask[j] = | ^ 3055 | raw_mask->pattern[i]; | In file included from ../drivers/net/i40e/i40e_flow.c:25: ../drivers/net/i40e/i40e_flow.c: In function 'i40e_flow_parse_fdir_filter': ../drivers/net/i40e/i40e_ethdev.h:630:17: note: at offset 16 into destination object 'flex_mask' of size 16 630 | uint8_t flex_mask[I40E_FDIR_MAX_FLEX_LEN]; | ^ In function 'i40e_flow_parse_fdir_pattern', inlined from 'i40e_flow_parse_fdir_filter' at ../drivers/net/i40e/i40e_flow.c:3274:8: ../drivers/net/i40e/i40e_flow.c:3052:69: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 3052 | filter->input.flow_ext.flexbytes[j] = | ^ 3053 | raw_spec->pattern[i]; | In file included from ../drivers/net/i40e/i40e_flow.c:25: ../drivers/net/i40e/i40e_flow.c: In function 'i40e_flow_parse_fdir_filter': ../drivers/net/i40e/i40e_ethdev.h:628:17: note: at offset [17, 271] into destination object 'flexbytes' of size 16 628 | uint8_t flexbytes[RTE_ETH_FDIR_MAX_FLEXLEN]; | ^ In function 'i40e_flow_parse_fdir_pattern', inlined from 'i40e_flow_parse_fdir_filter' at ../drivers/net/i40e/i40e_flow.c:3274:8: ../drivers/net/i40e/i40e_flow.c:3054:69: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 3054 | filter->input.flow_ext.flex_mask[j] = | ^ 3055 | raw_mask->pattern[i]; | In file included from ../drivers/net/i40e/i40e_flow.c:25: ../drivers/net/i40e/i40e_flow.c: In function 'i40e_flow_parse_fdir_filter': ../drivers/net/i40e/i40e_ethdev.h:630:17: note: at offset [17, 271] into destination object 'flex_mask' of size 16 630 | uint8_t flex_mask[I40E_FDIR_MAX_FLEX_LEN]; | ^ [2422/2422] Linking target app/test/dpdk-test -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 728] [dpdk-19.11.9-rc2]When compiling dpdk with make or meson under SUSE Linux Enterprise Server 15 SP2, the compilation fails
https://bugs.dpdk.org/show_bug.cgi?id=728 jiang,yu (yux.ji...@intel.com) changed: What|Removed |Added CC||yux.ji...@intel.com Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from jiang,yu (yux.ji...@intel.com) --- Test passed on LTS19.11.9-rc3 commit e5f56f22a82a1df49c224a8af13e769ff4b04cd8 Author: Christian Ehrhardt Date: Thu Jun 17 08:25:20 2021 +0200 version: 19.11.9-rc3 Signed-off-by: Christian Ehrhardt -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 732] [dpdk-19.11.9-rc2] DPDK build failed on Win10
https://bugs.dpdk.org/show_bug.cgi?id=732 jiang,yu (yux.ji...@intel.com) changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from jiang,yu (yux.ji...@intel.com) --- Test passed on LTS19.11.9-rc3 commit e5f56f22a82a1df49c224a8af13e769ff4b04cd8 Author: Christian Ehrhardt Date: Thu Jun 17 08:25:20 2021 +0200 version: 19.11.9-rc3 Signed-off-by: Christian Ehrhardt -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 744] [dpdk-19.11.9-rc3] make build failed on Fedora34 with GCC11
https://bugs.dpdk.org/show_bug.cgi?id=744 Bug ID: 744 Summary: [dpdk-19.11.9-rc3] make build failed on Fedora34 with GCC11 Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: yux.ji...@intel.com Target Milestone: --- [DPDK version]: e5f56f22a8 (HEAD, tag: v19.11.9-rc3, origin/19.11) version: 19.11.9-rc3 [OS version]: Fedora 34 (Server Edition)/5.12.10-300.fc34.x86_64 gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) (GCC) [Test Setup]: export RTE_TARGET=x86_64-native-linuxapp-gcc export RTE_SDK=`pwd` rm -rf x86_64-native-linuxapp-gcc rm -rf ./app/test/test_resource_c.res.o rm -rf ./app/test/test_resource_tar.res.o rm -rf ./app/test/test_pci_sysfs.res.o make -j 20 install T=x86_64-native-linuxapp-gcc MAKE_PAUSE=n Should support to build 19.11.9 with GCC11 or not? [Show the output from the previous commands]: PMDINFO hn_ethdev.o.pmd.c CC hn_ethdev.o.pmd.o LD hn_ethdev.o CC hn_rxtx.o In file included from /root/jaccy/dpdk/drivers/net/ice/base/ice_type.h:43, from /root/jaccy/dpdk/drivers/net/ice/base/ice_common.h:8, from /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.h:8, from /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.c:5: In function ‘ice_is_bit_set_internal’, inlined from ‘ice_is_bit_set’ at /root/jaccy/dpdk/drivers/net/ice/base/ice_bitops.h:85:9, inlined from ‘ice_get_recp_to_prof_map’ at /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.c:654:8, inlined from ‘ice_get_recp_frm_fw’ at /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.c:520:3, inlined from ‘ice_find_recp’ at /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.c:4695:8: /root/jaccy/dpdk/drivers/net/ice/base/ice_bitops.h:30:19: error: ‘r_bitmap’ may be used uninitialized [-Werror=maybe-uninitialized] 30 | return !!(*bitmap & BIT(nr)); | ^~~ /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.c: In function ‘ice_find_recp’: /root/jaccy/dpdk/drivers/net/ice/base/ice_switch.c:641:28: note: ‘r_bitmap’ declared here 641 | ice_declare_bitmap(r_bitmap, ICE_MAX_NUM_RECIPES); |^~~~ /root/jaccy/dpdk/drivers/net/ice/base/ice_bitops.h:26:22: note: in definition of macro ‘ice_declare_bitmap’ 26 | ice_bitmap_t A[BITS_TO_CHUNKS(sz)] | ^ CC ixgbe_phy.o PMDINFO igb_ethdev.o.pmd.c CC igb_ethdev.o.pmd.o CC ixgbe_api.o LD igb_ethdev.o CC igb_pf.o CC ixgbe_vf.o CC bnxt_ethdev.o CC lio_23xx_vf.o CC bnxt_filter.o CC clip_tbl.o CC nfp_mutex.o PMDINFO rte_eth_null.o.pmd.c CC rte_eth_null.o.pmd.o CC igb_flow.o CC em_ethdev.o CC em_rxtx.o LD rte_eth_null.o AR librte_pmd_null.a CC base/vnic_rq.o CC hns3_stats.o INSTALL-LIB librte_pmd_null.a CC hns3_regs.o CC hns3_dcb.o CC hns3_mp.o CC hinic_pmd_ethdev.o CC lio_mbox.o CC ixgbe_hv_vf.o CC ice_flex_pipe.o CC nfp_resource.o CC mps_tcam.o CC l2t.o CC ixgbe_dcb.o CC enic_rxtx_vec_avx2.o PMDINFO em_ethdev.o.pmd.c CC em_ethdev.o.pmd.o LD em_ethdev.o CC t4vf_hw.o CC ixgbe_dcb_82599.o CC hn_rndis.o CC ixgbe_dcb_82598.o CC ixgbe_mbx.o CC ixgbe_rxtx.o cc1: all warnings being treated as errors AR librte_pmd_lio.a make[6]: *** [/root/jaccy/dpdk/mk/internal/rte.compile-pre.mk:116: ice_switch.o] Error 1 make[6]: *** Waiting for unfinished jobs CC nfp_crc.o CC nfp_mip.o INSTALL-LIB librte_pmd_lio.a CC ixgbe_ethdev.o CC bnxt_flow.o CC bnxt_hwrm.o CC bnxt_ring.o CC bnxt_rxq.o CC bnxt_rxr.o CC hinic_pmd_rx.o CC bnxt_stats.o CC bnxt_txq.o AR librte_pmd_e1000.a PMDINFO hinic_pmd_ethdev.o.pmd.c CC hinic_pmd_ethdev.o.pmd.o INSTALL-LIB librte_pmd_e1000.a AR librte_pmd_hns3.a CC bnxt_txr.o LD hinic_pmd_ethdev.o INSTALL-LIB librte_pmd_hns3.a CC bnxt_vnic.o CC bnxt_irq.o AR librte_pmd_enic.a INSTALL-LIB librte_pmd_enic.a CC nfp_nffw.o PMDINFO bnxt_ethdev.o.pmd.c CC bnxt_ethdev.o.pmd.o CC hn_nvs.o LD bnxt_ethdev.o CC hn_vf.o CC bnxt_util.o AR librte_pmd_cxgbe.a INSTALL-LIB librte_pmd_cxgbe.a == Build drivers/net/octeontx == Build drivers/net/octeontx2 CC rte_pmd_bnxt.o CC bnxt_rxtx_vec_sse.o == Build drivers/net/qede CC ixgbe_fdir.o CC nfp_hwinfo.o CC hinic_pmd_tx.o CC nfp_rtsym.o CC nfp_nsp.o CC i40e_rxtx_vec_sse.o CC i40e_ethdev_vf.o CC ixgbe_pf.o == Build drivers/net/ring AR librte_pmd_netvsc.a CC otx2_rx.o CC octeontx_rxtx.o INSTALL-LIB librte_pmd_netvsc.a == Build drivers/net/sfc CC nfp_nsp_cmds.o CC nfp_nsp_eth.o CC ecore_dev.o make[5]: *** [/root/jaccy/dpdk/mk/rte.subdir.mk:37: ice] Error 2 make[5]: *** Waiting for unfinished jobs CC ixgbe_flow.o SYMLINK-FILE include/rte_eth_ring.h CC rte_eth
[dpdk-dev] [Bug 745] performance-thread build failure with clang 12.0.1
https://bugs.dpdk.org/show_bug.cgi?id=745
Bug ID: 745
Summary: performance-thread build failure with clang 12.0.1
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: examples
Assignee: dev@dpdk.org
Reporter: alia...@nvidia.com
Target Milestone: ---
"""
$ meson --werror -Dexamples=all build && ninja-build -C build
...
...
../examples/performance-thread/pthread_shim/main.c:75:2: error: 'pthread_yield'
is deprecated: pthread_yield is deprecated, use sched_yield instead
[-Werror,-Wdeprecated-declarations]
pthread_yield();
^
/usr/include/pthread.h:478:3: note: 'pthread_yield' has been explicitly marked
deprecated here
__attribute_deprecated_msg__ ("\
^
/usr/include/sys/cdefs.h:292:19: note: expanded from macro
'__attribute_deprecated_msg__'
__attribute__ ((__deprecated__ (msg)))
"""
Reproduces on main (8050b61).
OS: Fedora 35 (rawhide)
meson: 0.58.0
ninja-build: 1.10.2
clang: 12.0.1 (Fedora 12.0.1~rc1-3.fc35)
clang version 12.0.0 in Fedora 34 doesn't reproduce.
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [Bug 721] Wrong event pointer in rx adapter
https://bugs.dpdk.org/show_bug.cgi?id=721 Pavan Nikhilesh Bhagavatula (pbhagavat...@marvell.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||pbhagavat...@marvell.com --- Comment #7 from Pavan Nikhilesh Bhagavatula (pbhagavat...@marvell.com) --- As Jay mentioned, the intent is to give the callback events generated in the current Rx cycle which the current code already does. Marking the bug as resolved. Pavan. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 746] net/mlx5: segfault on MPRQ pool exhaustion
https://bugs.dpdk.org/show_bug.cgi?id=746 Bug ID: 746 Summary: net/mlx5: segfault on MPRQ pool exhaustion Product: DPDK Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: dmitry.kozl...@gmail.com Target Milestone: --- When MPRQ is enabled and packets are delayed in the application, like it happens when doing IPv4 reassembly, a segfault occurs in mlx5 PMD: (gdb) bt #0 0x55b34ea047c6 in _mm256_storeu_si256 (__A=..., __P=0x80) at /usr/lib/gcc/x86_64-linux-gnu/10/include/avxintrin.h:928 #1 rte_mov32 (src=0x2299c9140 "", dst=0x80 ) at ../src/lib/librte_eal/x86/include/rte_memcpy.h:320 #2 rte_memcpy_aligned (n=60, src=0x2299c9140, dst=0x80) at ../src/lib/librte_eal/x86/include/rte_memcpy.h:847 #3 rte_memcpy (n=60, src=0x2299c9140, dst=0x80) at ../src/lib/librte_eal/x86/include/rte_memcpy.h:872 #4 mprq_buf_to_pkt (strd_cnt=1, strd_idx=0, buf=0x2299c8a00, len=60, pkt=0x18345f0c0, rxq=0x18345ef40) at ../src/drivers/net/mlx5/mlx5_rxtx.h:820 #5 rxq_copy_mprq_mbuf_v (rxq=0x18345ef40, pkts=0x7f76e0ff6d18, pkts_n=5) at ../src/drivers/net/mlx5/mlx5_rxtx_vec.c:233 #6 0x55b34ea0c543 in rxq_burst_mprq_v (rxq=0x18345ef40, pkts=0x7f76e0ff6d18, pkts_n=46, err=0x7f76e0ff6a28, no_cq=0x7f76e0ff6a27) at ../src/drivers/net/mlx5/mlx5_rxtx_vec.c:456 #7 0x55b34ea0c82e in mlx5_rx_burst_mprq_vec (dpdk_rxq=0x18345ef40, pkts=0x7f76e0ff6a88, pkts_n=128) at ../src/drivers/net/mlx5/mlx5_rxtx_vec.c:528 #8 0x55b34d642e83 in rte_eth_rx_burst (nb_pkts=128, rx_pkts=0x7f76e0ff6a88, queue_id=, port_id=) at /opt/dpdk/include/rte_ethdev.h:4889 (application stack follows) No crash dumps are created by mlx5 PMD. Unfortunately, it is not reproducible with public tools, like testpmd, but more info can be provided if need be. HW: 2 x MT28800 Family [ConnectX-5 Ex] 1019 (2 x 2 x 100G) FW: 16.30.1004 OFED: MLNX_OFED_LINUX-5.3-1.0.0.1 DPDK: 21.02 EAL options: --in-memory --no-telemetry -a 21:00.0,mprq_en=1,dv_flow_en=0 -a 21:00.1,mprq_en=1,dv_flow_en=0 -a c1:00.0,mprq_en=1,dv_flow_en=0 -a c1:00.1,mprq_en=1,dv_flow_en=0 Conditions depend on the number of factors as shown below. CPU: AMD EPYC 7502 (32 cores): Distro: Ubuntu 20.04.2 LTS Kernel: 5.4.0-66-lowlatency UCTX_EN=0: mprq_en=0,dv_flow_en=0 - ok mprq_en=0,dv_flow_en=1 - ok mprq_en=1,dv_flow_en=0 - fail mprq_en=1,dv_flow_en=1 - fail UCTX_EN=1: mprq_en=0,dv_flow_en=0 - ok mprq_en=0,dv_flow_en=1 - ok mprq_en=1,dv_flow_en=0 - fail mprq_en=1,dv_flow_en=1 - ok CPU: Intel(R) Xeon(R) Gold 6238R CPU @ 2.20GHz (112 cores, HT) Distro: Debian 10.8 Kernel: 4.19.0-13 UCTX_EN=0: mprq_en=0,dv_flow_en=0 - ok mprq_en=0,dv_flow_en=1 - ok mprq_en=1,dv_flow_en=0 - fail mprq_en=1,dv_flow_en=1 - fail UCTX_EN=1: mprq_en=0,dv_flow_en=0 - ok mprq_en=0,dv_flow_en=1 - ok mprq_en=1,dv_flow_en=0 - ok mprq_en=1,dv_flow_en=1 - ok -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 747] [dpdk-19.11.9-rc3] Meson build failed with ICC-19.1.1
https://bugs.dpdk.org/show_bug.cgi?id=747 Bug ID: 747 Summary: [dpdk-19.11.9-rc3] Meson build failed with ICC-19.1.1 Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: yux.ji...@intel.com Target Milestone: --- [DPDK version]: e5f56f22a8 (HEAD, tag: v19.11.9-rc3, origin/19.11) version: 19.11.9-rc3 [OS version]: CENTOS83-64, kernel 4.18.0 ICC19.1.1 UB2004-64, kernel 5.8.0 ICC19.1.1 [Test Setup]: CC=icc meson --werror -Denable_kmods=True -Dlibdir=lib -Dexamples=all --default-library=static x86_64-native-linuxapp-icc ninja -C x86_64-native-linuxapp-icc -j 40 Should support to meson build 19.11.9 with ICC19.1.1 or not? [Notes] 1, Make build passed with ICC19.1.1 2, Meson build 19.11 also failed with ICC19.1.1 [CENTOS83-64 log as below] "FAILED: lib/librte_ethdev.a.p/librte_ethdev_rte_tm.c.o 16:27:31 icc -Ilib/librte_ethdev.a.p -Ilib -I../lib -Ilib/librte_ethdev -I../lib/librte_ethdev -I. -I.. -Iconfig -I../config -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -I../lib/librte_eal/linux/eal/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include/arch/x86 -I../lib/librte_eal/common/include/arch/x86 -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_meter -I../lib/librte_meter -pipe -D_FILE_OFFSET_BITS=64 -Wall -w3 -diag-disable:remark -Werror -O3 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native -mno-avx512f -DALLOW_EXPERIMENTAL_API -MD -MQ lib/librte_ethdev.a.p/librte_ethdev_rte_tm.c.o -MF lib/librte_ethdev.a.p/librte_ethdev_rte_tm.c.o.d -o lib/librte_ethdev.a.p/librte_ethdev_rte_tm.c.o -c ../lib/librte_ethdev/rte_tm.c 16:27:31 In file included from ../lib/librte_ethdev/rte_ethdev.h(159), 16:27:31 from ../lib/librte_ethdev/rte_tm.c(8): 16:27:31 ../lib/librte_net/rte_ether.h(222): error #2203: cast discards qualifiers from target type 16:27:31uint16_t *from_words = (uint16_t *)(ea_from->addr_bytes);" [UB2004-64 log as below] "FAILED: lib/librte_net.a.p/librte_net_rte_ether.c.o 16:27:31 icc -Ilib/librte_net.a.p -Ilib -I../lib -Ilib/librte_net -I../lib/librte_net -I. -I.. -Iconfig -I../config -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -I../lib/librte_eal/linux/eal/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include/arch/x86 -I../lib/librte_eal/common/include/arch/x86 -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -pipe -D_FILE_OFFSET_BITS=64 -Wall -w3 -diag-disable:remark -Werror -O3 -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=native -DALLOW_EXPERIMENTAL_API -MD -MQ lib/librte_net.a.p/librte_net_rte_ether.c.o -MF lib/librte_net.a.p/librte_net_rte_ether.c.o.d -o lib/librte_net.a.p/librte_net_rte_ether.c.o -c ../lib/librte_net/rte_ether.c 16:27:31 In file included from ../lib/librte_net/rte_ether.c(7): 16:27:31 ../lib/librte_net/rte_ether.h(222): error #2203: cast discards qualifiers from target type 16:27:31uint16_t *from_words = (uint16_t *)(ea_from->addr_bytes); 16:27:31 ^ 16:27:31 16:27:31 compilation aborted for ../lib/librte_net/rte_ether.c (code 2) 16:27:31 [77/2184] Compiling C object lib/librte_eal.a.p/librte_eal_linux_eal_eal_memory.c.o 16:27:31 [78/2184] Compiling C object lib/librte_net.a.p/librte_net_rte_arp.c.o 16:27:31 FAILED: lib/librte_net.a.p/librte_net_rte_arp.c.o 16:27:31 icc -Ilib/librte_net.a.p -Ilib -I../lib -Ilib/librte_net -I../lib/librte_net -I. -I.. -Iconfig -I../config -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -I../lib/librte_eal/linux/eal/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include/arch/x86 -I../lib/librte_eal/common/include/arch/x86 -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_ring -I../lib/librte_ring -pipe -D_FILE_OFFSET_BITS=64 -
[dpdk-dev] [Bug 749] mlx5: ConnectX-6 not all missed packets accounted for when using large maximum packet size
https://bugs.dpdk.org/show_bug.cgi?id=749 Bug ID: 749 Summary: mlx5: ConnectX-6 not all missed packets accounted for when using large maximum packet size Product: DPDK Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: martin.wei...@allegro-packets.com Target Milestone: --- Version: 21.05 (which is not available in the Bugzilla version field) When testing with ConnectX-6 we recently became aware that a lot of missed packets did not show up in the statistics. After some further testing it looks like this is somehow related to using a large maximum packet size (which I believe makes the driver use a different scatter-gather receive path). The following testpmd invocations can be used to demonstrate this behavior. First an example for a "normal" run without the large maximum packet size: ./app/dpdk-testpmd -a c1:00.0 -a c1:00.1 -n 4 --legacy-mem -- --total-num-mbufs=200 --rx-offloads=0x2800 --mbuf-size=2331 --rxd=4096 The xstats for one port look like this: rx_good_packets: 540138902 tx_good_packets: 537739805 rx_good_bytes: 298771912199 tx_good_bytes: 171950534158 rx_missed_errors: 572790 rx_errors: 0 tx_errors: 0 rx_mbuf_allocation_errors: 0 rx_q0_packets: 540138902 rx_q0_bytes: 298771912199 rx_q0_errors: 0 tx_q0_packets: 537739805 tx_q0_bytes: 171950534158 rx_wqe_errors: 0 rx_unicast_packets: 540711692 rx_unicast_bytes: 301254119575 tx_unicast_packets: 537739805 tx_unicast_bytes: 171950534158 rx_multicast_packets: 0 rx_multicast_bytes: 0 tx_multicast_packets: 0 tx_multicast_bytes: 0 rx_broadcast_packets: 0 rx_broadcast_bytes: 0 tx_broadcast_packets: 0 tx_broadcast_bytes: 0 tx_phy_packets: 537739805 rx_phy_packets: 540719221 rx_phy_crc_errors: 0 tx_phy_bytes: 174101493378 rx_phy_bytes: 301258662491 rx_phy_in_range_len_errors: 0 rx_phy_symbol_errors: 0 rx_phy_discard_packets: 7529 tx_phy_discard_packets: 0 tx_phy_errors: 0 rx_out_of_buffer: 0 tx_pp_missed_interrupt_errors: 0 tx_pp_rearm_queue_errors: 0 tx_pp_clock_queue_errors: 0 tx_pp_timestamp_past_errors: 0 tx_pp_timestamp_future_errors: 0 tx_pp_jitter: 0 tx_pp_wander: 0 tx_pp_sync_lost: 0 For this particular testcase the sum of rx_good_packets, rx_missed_errors and rx_phy_discard_packets is always the expected total packet count of 540719221. If however testpmd is invoked like this: ./app/dpdk-testpmd -a c1:00.0 -a c1:00.1 -n 4 --legacy-mem -- --total-num-mbufs=200 --max-pkt-len=15360 --rx-offloads=0x2800 --mbuf-size=2331 --rxd=4096 The xstats after the testcase run look like this: rx_good_packets: 521670616 tx_good_packets: 522641593 rx_good_bytes: 288980135079 tx_good_bytes: 167591285708 rx_missed_errors: 879662 rx_errors: 0 tx_errors: 0 rx_mbuf_allocation_errors: 0 rx_q0_packets: 521670616 rx_q0_bytes: 288980135079 rx_q0_errors: 0 tx_q0_packets: 522641593 tx_q0_bytes: 167591285708 rx_wqe_errors: 0 rx_unicast_packets: 522550278 rx_unicast_bytes: 291559156800 tx_unicast_packets: 522641593 tx_unicast_bytes: 167591285708 rx_multicast_packets: 0 rx_multicast_bytes: 0 tx_multicast_packets: 0 tx_multicast_bytes: 0 rx_broadcast_packets: 0 rx_broadcast_bytes: 0 tx_broadcast_packets: 0 tx_broadcast_bytes: 0 tx_phy_packets: 522641593 rx_phy_packets: 540719221 rx_phy_crc_errors: 0 tx_phy_bytes: 169681852080 rx_phy_bytes: 301258662491 rx_phy_in_range_len_errors: 0 rx_phy_symbol_errors: 0 rx_phy_discard_packets: 30665 tx_phy_discard_packets: 0 tx_phy_errors: 0 rx_out_of_buffer: 0 tx_pp_missed_interrupt_errors: 0 tx_pp_rearm_queue_errors: 0 tx_pp_clock_queue_errors: 0 tx_pp_timestamp_past_errors: 0 tx_pp_timestamp_future_errors: 0 tx_pp_jitter: 0 tx_pp_wander: 0 tx_pp_sync_lost: 0 The rx_good_packets, rx_missed_errors and rx_phy_discard_packets counters never sum up to the expected packet count: 521670616 + 879662 + 30665 = 522580943 540719221 - 522580943 = 18138278 (packets not accounted for) -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 720] clang add -Db_sanitize=address compilation option compilation failed
https://bugs.dpdk.org/show_bug.cgi?id=720 Peng,Zhihong (zhihongx.p...@intel.com) changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Peng,Zhihong (zhihongx.p...@intel.com) --- Test pass, commit: 8050b61562723c531ad9d4736f5549050eba190e -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 751] DPDK build error with gcc-12
https://bugs.dpdk.org/show_bug.cgi?id=751 Bug ID: 751 Summary: DPDK build error with gcc-12 Product: DPDK Version: 20.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: ferruh.yi...@intel.com Target Milestone: --- Created attachment 165 --> https://bugs.dpdk.org/attachment.cgi?id=165&action=edit ninja log Issue seen with gcc 12.0.0 "gcc (GCC) 12.0.0 20210704 (experimental)" The error related to `rte_memcpy()` AVX implementation. Build log is attached. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 733] [dpdk-19.11.9-rc2] make and meson build failed on Fedora33 with CLang11.0.0 and Fedora34 with Clang12.0.0
https://bugs.dpdk.org/show_bug.cgi?id=733 Christian Ehrhardt (christian.ehrha...@canonical.com) changed: What|Removed |Added Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #9 from Christian Ehrhardt (christian.ehrha...@canonical.com) --- Resolved in 19.11.9-rc4 and finally released in a bit via 19.11.9 Thanks for the testing. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 752] Leak in ice init if ice_flow_init or ice_reset_fxp_resource fails
https://bugs.dpdk.org/show_bug.cgi?id=752 Bug ID: 752 Summary: Leak in ice init if ice_flow_init or ice_reset_fxp_resource fails Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: major Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: david.march...@redhat.com CC: haiyue.w...@intel.com, qiming.y...@intel.com, qi.z.zh...@intel.com Target Milestone: --- Caught by code review while fixing another leak. If any of the two mentionned function fails, we have a leak on various resources, like DMA memzones for this port. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [Bug 723] pci_scan_one function has memory leak
https://bugs.dpdk.org/show_bug.cgi?id=723 Peng,Zhihong (zhihongx.p...@intel.com) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Peng,Zhihong (zhihongx.p...@intel.com) --- Test pass. Commit: 7c83a1e3c83e601f449f05e2e36e1df50e8503aa -- You are receiving this mail because: You are the assignee for the bug.
[DPDK/DTS Bug 1486] Port over rte_flow suite from old dts
https://bugs.dpdk.org/show_bug.cgi?id=1486 Bug ID: 1486 Summary: Port over rte_flow suite from old dts Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: DTS Assignee: dev@dpdk.org Reporter: dm...@iol.unh.edu CC: juraj.lin...@pantheon.tech, pr...@iol.unh.edu Target Milestone: --- -- You are receiving this mail because: You are the assignee for the bug.
[DPDK/cryptodev Bug 1487] blockcipher_test_case_run() does not log test_msg
https://bugs.dpdk.org/show_bug.cgi?id=1487 Bug ID: 1487 Summary: blockcipher_test_case_run() does not log test_msg Product: DPDK Version: 24.07 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: cryptodev Assignee: dev@dpdk.org Reporter: jack.bond-pres...@arm.com Target Milestone: --- app/test/test_cryptodev_blockcipher.c:blockcipher_test_case_run() allocates a test_msg string and the test function it calls writes useful output to this. However, the string is never used, so this useful logging is never provided - even in the event of (unexpected) failures. -- You are receiving this mail because: You are the assignee for the bug.
