Re: Compiling testpmd with DPDK netvsc PMD
marchan/builds/main/build-gcc-shared/drivers/librte_common_octeontx.so.24.2 [ snip ] EAL: open shared lib /home/dmarchan/builds/main/build-gcc-shared/drivers/librte_net_netvsc.so.24.2 EAL: pmd.net.netvsc.init log level changed from disabled to notice EAL: pmd.net.netvsc.driver log level changed from disabled to notice EAL: open shared lib /home/dmarchan/builds/main/build-gcc-shared/drivers/librte_net_null.so.24.2 EAL: pmd.net.null log level changed from disabled to notice [ snip ] -- David Marchand
Re: Compiling testpmd with DPDK netvsc PMD
Hello, On Sat, Jun 8, 2024 at 1:32 AM Nandini Rangaswamy wrote: > Thanks for your email. I inspected meson build output and do see that netvsc > is in the list of enabled drivers. > === > Drivers Enabled > === > > common: > iavf, mlx5, qat, > bus: > auxiliary, pci, vdev, vmbus, > mempool: > bucket, ring, stack, > dma: > > net: > af_packet, bond, e1000, ena, failsafe, gve, i40e, iavf, > ice, igc, ixgbe, kni, mlx5, netvsc, ring, tap, > vdev_netvsc, vhost, virtio, vmxnet3, Ok, so the driver seems indeed part of this build, yet it was not functional at runtime? Could you confirm this driver was indeed embeeded in (*statically* linked) testpmd? $ ./usertools/dpdk-pmdinfo.py build/app/dpdk-testpmd | grep -i vsc "name": "net_netvsc", "name": "net_vdev_netvsc", > > Also, i changed the meson.build default_library=shared from static and it > worked. Mm, the fact that changing link mode fixes the issue points at a link issue. There is a bug with old pkg-config tool (<= 0.27 iirc) that does not process correctly dpdk .pc (for static link). It is worth checking which version of pkgconf is used in openwrt. -- David Marchand
Re: Compiling testpmd with DPDK netvsc PMD
Hello, On Thu, Jun 6, 2024 at 11:32 PM Nandini Rangaswamy wrote: > I tried compiling the testpmd with DPDK netvsc for openwrt by setting > CONFIG_RTE_LIBRTE_NETVSC_PMD=y . > > However, when I check ldd testpmd, it does not show any of the dpdk shared > libraries including net_netvsc linked to testpmd binary. > ldd dpdk-testpmd > linux-vdso.so.1 (0x7ffca1467000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ffb08134000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffb0812f000) > libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 > (0x7ffb08111000) > libpcap.so.1 => not found > libmlx5.so.1 => /usr/lib/x86_64-linux-gnu/libmlx5.so.1 > (0x7ffb08093000) > libibverbs.so.1 => /usr/lib/x86_64-linux-gnu/libibverbs.so.1 > (0x7ffb0806d000) > libIPSec_MB.so.1 => not found > libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 > (0x7ffb07c29000) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7ffb07c09000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7ffb07c04000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffb079db000) > /lib64/ld-linux-x86-64.so.2 (0x7ffb097c1000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ffb079bd000) > libnl-route-3.so.200 => > /usr/lib/x86_64-linux-gnu/libnl-route-3.so.200 (0x7ffb0793a000) > libnl-3.so.200 => /lib/x86_64-linux-gnu/libnl-3.so.200 > (0x7ffb07917000) I am not sure what openwrt does wrt DPDK compilation, yet I can give some hints. DPDK drivers are, by default, statically linked into dpdk binaries like testpmd, so netvsc would not show up in this listing you tried. On the other hand, if using dynamically linked drivers, testpmd is not linked to them. Instead, those shared libraries are found automatically (for a DPDK global install) or via the -d EAL option. Then EAL loads those drivers via dlopen(). If you want to ensure that a specific driver is linked in, you may inspect meson output (which lists enabled drivers), or have a try with dpdk-pmd-info.py /path/to/dpdk-testpmd. HTH, -- David Marchand
Re: cannot trx when use testpmd
Hello, On Fri, Apr 12, 2024 at 9:51 AM hao wang wrote: > > I have a pmd that I am upstreaming to DPDK and currently testing. When I use > testpmd to test my pmd, I found that my pmd could trx in DPDK 23.07, but it > cannot in DPDK 23.11. After comparing the atlantic pmd between DPDK 23.07 and > 23.11, I see nearly no changes. I see the testpmd difference between DPDK > 23.07 and DPDK 23.11 and think these changes may not cause the problem. > > But when I use pktgen to test the pmd, it's ok. > > Any suggestions? Nothing comes to mind. The simpler is to do a bisect. -- David Marchand
Re: [E810 Offload VLAN Stripping]
Hello Carlos, John, On Tue, Mar 12, 2024 at 9:10 PM Carlos de Souza Moraes Neto wrote: > > I think i messed up in some part and know it is working. I'm using testpmd to > read tagged packets (IEC Sampled Values) that come to that port. Carlos, Thanks for the confirmation that reverting de5da9d16430 works for you. I opened a bz: https://bugs.dpdk.org/show_bug.cgi?id=1402 John, We mentionned this (E810 vlan stripping) issue during the maintainers call this morning. Please can you find someone at Intel to look into it? Thanks. -- David Marchand
Re: [E810 Offload VLAN Stripping]
Hello Carlos, On Mon, Mar 11, 2024 at 7:07 PM Carlos de Souza Moraes Neto wrote: > It worked in 22.11 but when I tried 23.11 and revert de5da9d16430 it didn’t > work. Are you testing with testpmd? If not, please double check first with testpmd. And describe the traffic you are testing with. With this, I hope Intel can reproduce your issue. -- David Marchand
Re: [E810 Offload VLAN Stripping]
Hello Carlos,
On Mon, Mar 11, 2024 at 10:29 AM Carlos de Souza Moraes Neto
wrote:
> Hello,
>
Adding some Intel folks.
> I'm currently working on enabling the RTE_ETH_RX_OFFLOAD_VLAN_STRIP offload
> feature to strip VLAN tags and store the VLAN information in the vlan_tci
> field while using an Intel E810-XXVDA2 NIC. However, the VLAN tags are not
> being stripped. I’ve already tried to update DPDK (23.11), E810 firmware
> (4.40), ICE and DDP (1.3.35.0) but nothing. My console output is:
>
> EAL: Detected CPU lcores: 8
> EAL: Detected NUMA nodes: 1
> EAL: Detected shared linkage of DPDK
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> EAL: Selected IOVA mode 'VA'
> EAL: VFIO support initialized
> EAL: Using IOMMU type 1 (Type 1)
> EAL: Probe PCI driver: net_ice (8086:159b) device: :01:00.0 (socket -1)
> ice_load_pkg_type(): Active package is: 1.3.35.0, ICE OS Default Package
> (single VLAN mode)
> EAL: Probe PCI driver: net_ice (8086:159b) device: :01:00.1 (socket -1)
> ice_load_pkg_type(): Active package is: 1.3.35.0, ICE OS Default Package
> (single VLAN mode)
> EAL: Probe PCI driver: net_e1000_igb (8086:1521) device: :02:00.0 (socket
> -1)
> EAL: Probe PCI driver: net_e1000_igb (8086:1521) device: :02:00.1 (socket
> -1)
> EAL: Probe PCI driver: net_e1000_igb (8086:1521) device: :02:00.2 (socket
> -1)
> EAL: Probe PCI driver: net_e1000_igb (8086:1521) device: :02:00.3 (socket
> -1)
> TELEMETRY: No legacy callbacks, legacy socket not created
> ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 0).
> ice_set_tx_function(): Using AVX2 OFFLOAD Vector Tx (port 0).
> ice_vsi_config_outer_vlan_stripping(): Single VLAN mode (SVM) does not
> support qinq
> ice_set_rx_function(): Using AVX2 OFFLOAD Vector Rx (port 1).
> ice_set_tx_function(): Using AVX2 OFFLOAD Vector Tx (port 1).
> ice_vsi_config_outer_vlan_stripping(): Single VLAN mode (SVM) does not
> support qinq
I think I reproduce your issue (though I see messages claiming support
for double VLAN in my setup).
I tested with testpmd in v23.11 and a E810 nic:
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller
E810-XXV for SFP (rev 02)
# ./build/app/dpdk-testpmd -a :04:00.0 -- --enable-hw-vlan-strip -i
...
ice_load_pkg_type(): Active package is: 1.3.30.0, ICE OS Default
Package (double VLAN mode)
...
testpmd> set verbose 1
Change verbose level from 0 to 1
testpmd> start
...
port 0/queue 0: received 1 packets
src=00:00:00:00:00:00 - dst=FF:FF:FF:FF:FF:FF - pool=mb_pool_0 -
type=0x8100 - length=60 - nb_segs=1 - hw ptype: L2_ETHER
L3_IPV4_EXT_UNKNOWN L4_NONFRAG - sw ptype: L2_ETHER_VLAN L3_IPV4 -
l2_len=18 - l3_len=20 - Receive queue=0x0
ol_flags: RTE_MBUF_F_RX_L4_CKSUM_GOOD RTE_MBUF_F_RX_IP_CKSUM_GOOD
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD
I did a bisect, v22.11 worked for me and I ended up on: de5da9d16430
("net/ice: support double VLAN") as the first bad commit.
Reverting it restores vlan stripping for me on RHEL9.
port 0/queue 0: received 1 packets
src=00:00:00:00:00:00 - dst=FF:FF:FF:FF:FF:FF - pool=mb_pool_0 -
type=0x0800 - length=60 - nb_segs=1 - VLAN tci=0x2a - hw ptype:
L2_ETHER L3_IPV4_EXT_UNKNOWN L4_NONFRAG - sw ptype: L2_ETHER L3_IPV4
- l2_len=14 - l3_len=20 - Receive queue=0x0
ol_flags: RTE_MBUF_F_RX_VLAN RTE_MBUF_F_RX_L4_CKSUM_GOOD
RTE_MBUF_F_RX_IP_CKSUM_GOOD RTE_MBUF_F_RX_VLAN_STRIPPED
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD
Carlos, do you see the same?
Bruce, Vladimir, could you have a look and confirm on your side?
Thanks!
--
David Marchand
Re: How to enable logging and where to find the logs
Hello, On Thu, Feb 29, 2024 at 9:51 AM Sindhura Bandi wrote: > > I might be asking a basic question here. I'm facing some issues while > bringing up a dpdk interface on ovs-dpdk on debian-12. Dpdk version is > 22.11.1. > Dpdk seems to fail to allocate a mempool, even though there seem to be enough > free huge page memory available on the machine. > Well, this is more a OVS question than a DPDK one :-) There are two things to configure here. > I tried to enable dpdk debugs using the following command, > ovs-vsctl set Open_vSwitch . > other_config:dpdk-extra="--log-level=lib.mbuf:debug" First, as you tried, you must ask DPDK to emit debug logs for the mbuf library. The above configuration is fine. Just a small note that since OVS 2.14 you can enable logs dynamically without having to restart OVS / setting a dpdk-extra param in ovsdb. For example, I have no dpdk-extra config. # ovs-appctl dpdk/log-list | grep mbuf id 16: lib.mbuf, level is info # ovs-appctl dpdk/log-set lib.mbuf:debug # ovs-appctl dpdk/log-list | grep mbuf id 16: lib.mbuf, level is debug > > The command was accepted, but I don't see any logs from dpdk anywhere in my > /var/log. That is because OVS log framework applies a filter. # ovs-appctl vlog/list | grep dpdk dpdk OFFERR INFO netdev_dpdkOFFERR INFO netdev_offload_dpdk OFFERR INFO The dpdk facility here is only logging ERR level messages to syslog, and INFO level to the /var/log file. You probably want to set: # ovs-appctl vlog/set FILE:dpdk:dbg # ovs-appctl vlog/list | grep dpdk dpdk OFFERRDBG netdev_dpdkOFFERR INFO netdev_offload_dpdk OFF ERR INFO Hope that helps. -- David Marchand
Re: DPDK telemetry plugin for Collectd won't show DPDK application metrics
Hello, On Sat, Dec 30, 2023 at 4:12 PM rhjafrooz wrote: > > I want to use collectd's DPDK telemetry plugin for exporting metrics from > DPDK application. But it won't work. I had uncommented LoadPlugin > dpdk_telemetry, and my Collectd config for dpdk-telemetry is : > > > > ClientSocketPath "/var/run/dpdk/rte/mp_socket" > DpdkSocketPath "/var/run/dpdk/rte/dpdk_telemetry.v2" > > > > I expect Collectd to work as before, but when I open Collectd output metrics > (port 9103 by default), It won't show anything. > (NOTE: I'm running all of them on a single virtual machine in a VMware) I am not familiar with collectd. You may have some luck asking here about the dpdk plugin. However, I suggest you turn to the collectd community first to check that your collectd configuration is valid before looking at help from the dpdk side. -- David Marchand
Re: [dpdk-users] Unable to see traces from a user defined DPDK Tracepoint
Hello, Copying trace framework maintainers. On Fri, Oct 27, 2023 at 9:48 AM Sanjit Kumar wrote: > I am trying to test the usage of the DPDK trace library. I have run into the > same issue as recounted here - > https://mails.dpdk.org/archives/users/2020-December/005266.html - where I am > able to build and run my DPDK application where I have created and registered > my custom trace point (verified via rte_trace_dump(stdout) which says my > traces are 'enabled' - i see the right trace buffer size, trace file > destination etc). The trace point creation and registration are identical to > what is mentioned in the program guide using RTE_TRACE_POINT in a header file > and registering it in my dpdk application via RTE_TRACE_POINT_REGISTER macro. > > What I notice are as follows: > > 1. The program builds and runs as intended. > 2. The trace files are generated in the correct destination directory. > 3. On using trace=.* > I see a huge list of traces on viewing the trace > file with babeltrace - but do not see my custom trace point. I also do not > see any trace output from my dpdk application if I reuse DPDK library traces > ( eg: rte_eal_trace_thread_lcore_ready ) instead of defining my own custom > traces. > 4. On using trace= i do not see any > trace output just used inside my application. > > I think the above observations suggest that the issue might be in configuring > my DPDK application to recognize and create trace output properly. However > the rte_trace_dump output suggests that trace is enabled here. > > What I would like to know is similar to utkarsh's question: > Is there anything I am missing in configuring my application to recognize > traces? If so can you please point it out? I think a hint was posted later, about this topic. Did you compile your application tracepoint register code with -DALLOW_EXPERIMENTAL_API ? If you confirm it solves your issue, we need to enhance the trace framework documentation. -- David Marchand
Re: tap device speed
On Tue, Oct 3, 2023 at 6:01 PM Stephen Hemminger wrote: > > On Tue, 3 Oct 2023 10:49:16 +0200 > Antonio Di Bacco wrote: > > > I understand, could we use another solution ? Like a memif interface > > in DPDK and libmemif in Linux? > > The issue is accessing kernel networking devices. Both virtio user > and XDP are faster for that. Memif is for doing process to process networking. For dpdk <-> kernel, as you are mentioning virtio-user/vhost, let me add that there is some activity on this side, with VDUSE. Maxime is working on the VDUSE kernel and dpdk bits. He gave a talk about the current status during the summit and some performance numbers: https://dpdksummit2023.sched.com/event/1P9xA/vduse-performance-how-fast-is-it-maxime-coquelin-red-hat -- David Marchand
Re: Zero ports detected issue for Solarflare (SFC9250) cards
Hello, On Sun, Sep 10, 2023 at 8:05 PM wrote: > > > Hi all > > I'm trying to use Solarflare (SFC9250) cards with DPDK. I have > compiled the skeleton/basicfwd application but when I run it with the > following parameters, the number of ports becomes zero, and it can't > detect the Solarflare ports on the system. > > $ sudo examples/dpdk-skeleton -l 0 -n 2 > EAL: Detected CPU lcores: 10 > 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' > TELEMETRY: No legacy callbacks, legacy socket not created > EAL: Error - exiting with code: 1 >Cause: Error: number of ports (0) must be even > > Currently, the platform is using dpdk-stable-22.11.2 and CentOS 7 > > What am I doing wrong? I would greatly appreciate your assistance > > > hft_005@hft_005:~/volspace/dpdk-stable-22.11.2$ usertools/dpdk-devbind.py -s > > Network devices using kernel driver > === > :01:00.0 'XtremeScale SFC9250 10/25/40/50/100G Ethernet Controller > 0b03' if=enp1s0f0 drv=sfc unused= *Active* > :01:00.1 'XtremeScale SFC9250 10/25/40/50/100G Ethernet Controller > 0b03' if=enp1s0f1 drv=sfc unused= *Active* If you expect those two PCI devices above to be taken over by DPDK, you need to unbind them from the kernel net driver sfc and bind them to vfio-pci. https://doc.dpdk.org/guides-22.11/linux_gsg/linux_drivers.html#binding-and-unbinding-network-ports-to-from-the-kernel-modules Please keep in mind that you will lose connectivity to this system if you are connected through enp1s0f0 or enp1s0f1 netdevs. > :06:00.0 'I210 Gigabit Network Connection 1533' if=enp6s0 drv=igb > unused= *Active* > :07:00.0 'I210 Gigabit Network Connection 1533' if=enp7s0 drv=igb unused= > :08:00.0 'Ethernet Controller X710 for 10GBASE-T 15ff' if=enp8s0f0 > drv=i40e unused= > :08:00.1 'Ethernet Controller X710 for 10GBASE-T 15ff' if=enp8s0f1 > drv=i40e unused= -- David Marchand
Re: Implementing a simple TAP PMD to dpdk-vhost structure
On Wed, Sep 6, 2023 at 9:53 AM Nicolson Ken (ニコルソン ケン) wrote: > > Alternatively, did you consider using testpmd with the vhost pmd instead ? > > I've tried that before, but as far as I can see from net/vhost/rte_eth_host.c > it uses rte_vost_enqueue/dequeue_burst() to basically act as a loopback for > the Guest OS. I use: > > $ sudo dpdk-testpmd -l 0-3 -n 4 --vdev 'net_tap0' --vdev > 'net_vhost1,iface=/tmp/sock0,client=1' -- -i > > But if I feed data in using "tcpreplay -I dtap0 ...", "show port stats all" > shows everything going into the TAP but nothing is forward to vhost. Well, pinging from a dtap0 netdev in the host to a virtio-net netdev in a guest works me. testpmd> set verbose 3 Change verbose level from 0 to 3 testpmd> start io packet forwarding - ports=2 - cores=1 - streams=2 - NUMA support enabled, MP allocation mode: native Logical Core 1 (socket 1) forwards packets on 2 streams: RX P=0/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:01 RX P=1/Q=0 (socket 0) -> TX P=0/Q=0 (socket 0) peer=02:00:00:00:00:00 port 0/queue 0: received 16 packets src=26:9B:E2:29:7E:C6 - dst=33:33:00:00:00:16 - pool=mb_pool_0 - type=0x86dd - length=90 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV6_EXT - sw ptype: L2_ETHER L3_IPV6_EXT - l2_len=14 - l3_len=48 - Receive queue=0x0 ol_flags: RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN src=26:9B:E2:29:7E:C6 - dst=33:33:00:00:00:16 - pool=mb_pool_0 - type=0x86dd - length=90 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV6_EXT - sw ptype: L2_ETHER L3_IPV6_EXT - l2_len=14 - l3_len=48 - Receive queue=0x0 ol_flags: RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN src=26:9B:E2:29:7E:C6 - dst=33:33:FF:29:7E:C6 - pool=mb_pool_0 - type=0x86dd - length=86 - nb_segs=1 - hw ptype: L2_ETHER L3_IPV6 - sw ptype: L2_ETHER L3_IPV6 - l2_len=14 - l3_len=40 - Receive queue=0x0 ol_flags: RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN Are you seeing the vhost port getting initialised in testpmd output? How are you sure that nothing is forwarded? -- David Marchand
Re: Implementing a simple TAP PMD to dpdk-vhost structure
Hello Ken,
On Wed, Sep 6, 2023 at 3:56 AM Nicolson Ken (ニコルソン ケン)
wrote:
>
> Hi all,
>
> Using dpdk 22.11.2 on Ubuntu 22.04
>
> I have a really simple use case, but I cannot find how to implement it. I've
> set up QEMU with all the required virtio support, so I just need to configure
> my Host OS-side. I want to send data from a PCAP file via tcpreplay from the
> Host to the Guest, so I use this command line:
>
> $ sudo /home/integ/dpdk-stable-22.11.2/build/examples/dpdk-vhost -l 0-3 -n 4
> --socket-mem 1024 --vdev 'net_tap0' -- --socket-file /tmp/sock0 --client -p 1
>
> However, this fails with:
>
> EAL: Detected CPU lcores: 20
> 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'
> VHOST_PORT: Failed to get VMDq info.
> EAL: Error - exiting with code: 1
> Cause: Cannot initialize network ports
>
> The offending code is from examples/vhost/main.c:
>
> if (dev_info.max_vmdq_pools == 0) {
> RTE_LOG(ERR, VHOST_PORT, "Failed to get VMDq info.\n");
> return -1;
> }
>
> This is because the TAP PMD doesn't support VMDq pools.
>
> Is there an easy way to get this to work?
This sounds strange to require VMDq support...
Copying Maxime and Chenbo who probably know better about this example code.
Alternatively, did you consider using testpmd with the vhost pmd instead ?
--
David Marchand
Re: Virtio_user for kernel interface.
On Mon, Aug 28, 2023 at 10:07 AM Carlos de Souza Moraes Neto wrote: > I'm attempting to utilize virtio_user for packet transmission and reception > via the kernel's network stack. I transmitted packets from a NIC to > virtio_user0 and captured them on the tap0 interface. However, when trying to > send a packet from tap0 (for instance, a basic ping) and route it to DPDK, > the function rte_eth_rx_burst returns zero packets. My initialization is set > as follows: > -l 0-4 > --vdev=virtio_user0,path=/dev/vhost-net,queues=3,queue_size=1024. Just an idea. If you ask for 3 queue pairs, your application must poll packets from all 3 rxqs, as the kernel may choose to send packets through any of those queues. Are you perhaps only polling one rxq? -- David Marchand
Re: Dynamic Fields Zeroing
On Wed, Aug 9, 2023 at 3:24 PM Oleksandr Nahnybida wrote: > > Should I expect that mbuf that I get from rx_burst, won't have dynfield > zeroed, and I should do this myself? I think setting/clearing a dynfield is the responsibility of the component that registered it. Olivier, can you enlighten us? -- David Marchand
Re: Generic flow string parser
On Wed, Apr 26, 2023 at 6:47 AM Cliff Burdick wrote: > > Does anyone know if a generic parser for flow strings exists anywhere? The > one inside of testpmd is ideal, but unfortunately it's self-contained and not > distributed as part of a normal DPDK install. This seems like something that > is likely reinvented over and over and it would be useful if there was a > single API to take in strings and generate flows. I heard this same question in the past, but I don't remember the answer. Copying Thomas and Ori who might know. -- David Marchand
Re: when will DPDK support SM3 hmac
On Wed, Apr 12, 2023 at 8:59 AM Cai ZhongFei(Carrie Cai) wrote: > > I used DPDK to run test-crypto-perf and found out it only support sm3 hash > for now, do you have any plan about supporting sm3 hmac? Added cryptodev maintainer, Akhil. -- David Marchand
Re: MAX_MBUF_SIZE causes queue configuration failure.
Hello,
On Wed, Apr 12, 2023 at 8:59 AM Dhamodaran Pandiyan
wrote:
>
> When I set the value to MAX_MBUF_SIZE as less than 16256, all the
> initialization went through fine and the application was online.
>
> But when I increase the MAX_MBUF_SIZE to more than 16256 like 16257, 17000,
> or 18000, I get the attached log error which shows an issue in configuring
> the virtual queues for the NIC.
>
> Log Snip:
> i40evf_configure_vsi_queues(): Failed to execute command of
> VIRTCHNL_OP_CONFIG_VSI_QUEUES
> i40evf_dev_start(): configure queues failed
Added net/i40e driver maintainers.
This error indicates a failure either when sending a message to the PF
driver, or that the PF driver refused to configure this VF with the
passed parameters.
Assuming you are using the PF i40e driver, I tracked this message
handling to find that buffer size is limited (the exact limit is not
clear to me) probably due to some hw limitations.
See:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c#n4088
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c#n2371
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c#n714
/* max pkt. length validation */
if (info->max_pkt_size >= (16 * 1024) || info->max_pkt_size < 64) {
ret = -EINVAL;
goto error_param;
}
I'll let net/i40e reply with better details/explanations.
> MTU size for port id: is: 9000
> Failed to start the fast pkt for port_id : 1Ret: -1
>
> Some Observations:
> 1. Thought memory availability was an issue, so provided 10x more memory and
> allocated 10x huge pages than required, still noticed the same issue.
> 2. Got to know MTU size also plays a role in deciding the mbuf_size, so tried
> running app with MTU of less value, but still issue persists.
>
> Please someone enlighten me on what is happening here.
--
David Marchand
Re: ethtool-like command on ice pmd
Hello, On Wed, Apr 12, 2023 at 8:59 AM Ernesto Ruffini wrote: > I would like to configure an Intel E810 with something like > ethtool --set-priv-flags eno1 mdd-auto-reset-vf on > > Is there a way to do it from inside DPDK? > I tried to run the ethtool command before binding the nic to the DPDK driver, > but apparently the behaviour is reset once the binding takes place. Added net/ice maintainers. -- David Marchand
Re: Hardware timestamps
Hello, On Wed, Apr 12, 2023 at 8:57 AM Игорь К wrote: > > I have tried to get hw timestamps of packets on Intel X550T(10G) and > AQC107(10G). > But RTE_ETH_RX_OFFLOAD_TIMESTAMP = 0 in dev_info.rx_offload_capa. > Tell me is it possible to get hw timestamps on these NICs with DPDK? Looking at the doc, and the code, none of those drivers (net/ixgbe, net/atlantic) seem to support this feature. I'll let the maintainers reply on the feasibility. > Which 10G NICs support this option? The documentation from the main repository provides a list of per driver features: https://doc.dpdk.org/guides/nics/overview.html For an already released DPDK, the link becomes https://doc.dpdk.org/guides-/nics/overview.html. Like, for example: https://doc.dpdk.org/guides-22.11/nics/overview.html -- David Marchand
Re: enable ASAN issue when run on a Virtio PCI device
On Thu, Mar 9, 2023 at 2:44 PM David Marchand wrote: > On Thu, Mar 9, 2023 at 2:05 PM Pei, Andy wrote: > > I am running testpmd on a virtio PCI device, and encounter this issue when > > enable ASAN. > > > > I got this ERROR, > > > > check_vq_phys_addr_ok(): vring address shouldn't be above 16TB! > > virtio_init_queue(): setup_queue failed > > eth_virtio_pci_init(): Failed to init virtio device > > EAL: Releasing PCI mapped resource for :18:00.0 > > EAL: Calling pci_unmap_resource for :18:00.0 at 0x7fc9c000 > > EAL: Calling pci_unmap_resource for :18:00.0 at 0x7fc197a75000 > > EAL: Requested device :18:00.0 cannot be used > > EAL: Bus (pci) probe failed. > > TELEMETRY: No legacy callbacks, legacy socket not created > > testpmd: No probed ethernet devices > > > > > > How to fix this issue when ASAN is enabled, huge pages are all mapped to > > very high address, adding “--base-virtaddr” args does not works. > > I am not able to reproduce your issue. > You'll have to share more details about your setup. Actually, relooking at the code, I think we can do something on virtio side, for modern devices and Maxime seemed to agree. Can you have a try with: https://patchwork.dpdk.org/project/dpdk/patch/20230309143604.2354288-1-david.march...@redhat.com/ Thanks. -- David Marchand
Re: enable ASAN issue when run on a Virtio PCI device
t; /usr/lib64/libdl-2.17.so > 7fc9dcf9d000-7fc9dcf9e000 r--p 2000 08:03 536960226 > /usr/lib64/libdl-2.17.so > 7fc9dcf9e000-7fc9dcf9f000 rw-p 3000 08:03 536960226 > /usr/lib64/libdl-2.17.so > 7fc9dcf9f000-7fc9dd0a r-xp 08:03 536960228 > /usr/lib64/libm-2.17.so > 7fc9dd0a-7fc9dd29f000 ---p 00101000 08:03 536960228 > /usr/lib64/libm-2.17.so > 7fc9dd29f000-7fc9dd2a r--p 0010 08:03 536960228 > /usr/lib64/libm-2.17.so > 7fc9dd2a-7fc9dd2a1000 rw-p 00101000 08:03 536960228 > /usr/lib64/libm-2.17.so > 7fc9dd2a1000-7fc9dd2cb000 r-xp 08:03 671752690 > /usr/lib64/libasan.so.0.0.0 > 7fc9dd2cb000-7fc9dd4ca000 ---p 0002a000 08:03 671752690 > /usr/lib64/libasan.so.0.0.0 > 7fc9dd4ca000-7fc9dd4cb000 r--p 00029000 08:03 671752690 > /usr/lib64/libasan.so.0.0.0 > 7fc9dd4cb000-7fc9dd4cc000 rw-p 0002a000 08:03 671752690 > /usr/lib64/libasan.so.0.0.0 > 7fc9dd4cc000-7fc9e0231000 rw-p 00:00 0 > 7fc9e0231000-7fc9e0253000 r-xp 08:03 536960213 > /usr/lib64/ld-2.17.so > 7fc9e0253000-7fc9e0254000 rw-s 00:13 622044 > /run/dpdk/rte/fbarray_memseg-1048576k-0-0 > 7fc9e0254000-7fc9e043a000 rw-p 00:00 0 > 7fc9e043a000-7fc9e0452000 rw-p 00:00 0 > 7fc9e0452000-7fc9e0453000 r--p 00021000 08:03 536960213 > /usr/lib64/ld-2.17.so > 7fc9e0453000-7fc9e0454000 rw-p 00022000 08:03 536960213 > /usr/lib64/ld-2.17.so > 7fc9e0454000-7fc9e0455000 rw-p 00:00 0 > 7fff29f46000-7fff29f67000 rw-p 00:00 0 > [stack] > 7fff29fe9000-7fff29feb000 r-xp 00:00 0 > [vdso] > ff60-ff601000 r-xp 00:00 0 > [vsyscall] -- David Marchand
Re: DPDK installation error
Hello, On Fri, Mar 3, 2023 at 2:29 AM Roya Taheri wrote: > > Hi, I tried to install DPDK on Bluefield-2 on Cloudlab. The meson build > cannot find all the dependencies and libraries but it runs without errors. > After that ninja command show this error after the execution: > ../drivers/regex/cn9k/cn9k_regexdev_compiler.c:12:10: fatal error: > rxp-compiler.h: No such file or directory >12 | #include > | ^~~~ > compilation terminated. > I updated the version of the meson but nothing changed. Would please help me > with this issue? You are not the first to report this issue but nobody looked into the exact reason. You probably don't want to build this driver on Bluefield-2. So my simple advice is that you should disable this driver: $ meson configure -Ddisable_drivers=regex/cn9k -- David Marchand
Re: Add more lcores to application after rte_eal_init has been called
On Wed, Feb 22, 2023 at 4:05 PM Stephen Hemminger wrote: > > On Wed, 22 Feb 2023 14:10:20 +0100 > Antonio Di Bacco wrote: > > > I need to add some more cores to the application after the DPDK has > > already been initialised. > > Is it possible? > > No > > > For other resources like network cards, I managed to probe new cards > > dynamically but don't understand how I can do the same for new lcores. > > You can start with lots of cores, but only use some of them in your > application. The unused queues could wait on something like pthread_condition > that is blocking. > If you really want to go with a dynamic approach, you could do like OVS does which is to stop using EAL threads, but have everything in your applications: create threads + set their cpu affinity + register them as lcores. That's the *easy* part. Then, if you want to go and only configure the exact number of rxq/txq wrt to your datapath threads, next is that you need to reconfigure the existing ports when a change happens and you will need to stop your existing datapath threads from pulling packets before reconfiguring the ports. Stephen description is probably the best/least effort. -- David Marchand
Re: Re: l2fwd: Requested device 0000:02:00.0 cannot be used (Ubuntu 22.04, DPDK 22.07, N5095, I225-V)
On Tue, Oct 4, 2022 at 8:33 AM F32 wrote:
>
> Thanks for the suggestion.
>
> I took half an hour to add debug logs layer by layer and finally I came to
> igc_init_phy_params_i225 in drivers/net/igc/base/igc_i225.c.
>
> There is a piece of code that looks like this in the function:
>
> > /* Verify phy id and set remaining function pointers */
> > switch (phy->id) {
> > case I225_I_PHY_ID:
> > case I226_LM_PHY_ID:
> > phy->type = igc_phy_i225;
> > phy->ops.set_d0_lplu_state = igc_set_d0_lplu_state_i225;
> > phy->ops.set_d3_lplu_state = igc_set_d3_lplu_state_i225;
> > /* TODO - complete with GPY PHY information */
> > break;
> > default:
> > ret_val = -IGC_ERR_PHY;
> > goto out;
> > }
>
> The supported I225 model is I225_I with PHY_ID 0x67C9DC00, but the adapters
> on my Mini-PC are I225_V with PHY_ID 0x67C9DCC0.
> After adding the case l2fwd is now working.
A recent change in this area of the driver got merged in next-net-intel.
c493e5ee25fe ("net/igc: remove unncessary PHY ID checking")
Cc: igc maintainers and authors of the change
>
> BTW, I noticed that there are so many different cases (in different source
> files) which might generate the "Requested device xxx cannot be used" error.
> Introducing a standard error code may be hellpful for ordinary dpdk users,
> but it requires lots of work.
I don't see how this is feasible to standardize error codes that would
help here.
The less awful is to get debug log messages, which is the driver responsibility.
--
David Marchand
Re: how to bind VF interface into dpdk
On Wed, Sep 14, 2022 at 2:30 PM Balakrishnan K wrote: > > I am trying to bind VF interface to dpdk using dpdk-devbind.py. > > Unable to bind getting error “cannot bind to driver uio_pci_generic”. > > Steps followed: > > 1.modprobe uio_pci_generic > > 2. dpdk-devbind.py -b uio_pci_generic :05:00.0 In general, you should use vfio-pci. Now, for your particular case, ixgbe VF devices (10ed) won't work with uio_pci_generic, and it is reported in the driver info. $ ./usertools/dpdk-pmdinfo.py build-gcc/drivers/librte_net_ixgbe.so | less PMD NAME: net_ixgbe_vf PMD PARAMETERS: pflink_fullchk=<0|1> PMD KMOD DEPENDENCIES: * igb_uio | vfio-pci PMD HW SUPPORT: Intel Corporation (8086) : 82599 Ethernet Controller Virtual Function (10ed) (All Subdevices) Intel Corporation (8086) : 82599 Virtual Function (152e) (All Subdevices) Intel Corporation (8086) : X540 Ethernet Controller Virtual Function (1515) (All Subdevices) Intel Corporation (8086) : X540 Virtual Function (1530) (All Subdevices) Intel Corporation (8086) : X550 Virtual Function (1564) (All Subdevices) Intel Corporation (8086) : X550 Virtual Function (1565) (All Subdevices) Intel Corporation (8086) : X553 Virtual Function (15c5) (All Subdevices) Intel Corporation (8086) : X553 Virtual Function (15b4) (All Subdevices) Intel Corporation (8086) : Ethernet Connection X552 Virtual Function (15a8) (All Subdevices) Intel Corporation (8086) : X552 Virtual Function (15a9) (All Subdevices) ... > > Also tried with vfio-pci driver not succeeded. We need dmesg output in this case, to be sure. In general, it means that either your system has no iommu (there is a special *unsafe* mode, for handling this case), or the iommu is not configured. Please see https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html#vfio -- David Marchand
Re: Couple of build problems ( Fedora 36, DPDK 21.11.1 )
On Wed, Jul 20, 2022 at 6:12 PM Mark de Roussier wrote: > > >then maybe you did not reconfigure your build env. > >$ meson --reconfigure > > . I tried many meson commands to wipe/reconfigure my build environment, but > I've just blown away the whole build directory and started again, and now it > appears to be working ( though I thought I'd tried that before too ). Maybe I > missed a trick with reconfiguring meson, I don't know. The PC has also been > restarted a few times. The ninja build succeeds ( with warnings ). Those warnings may be what I have fixed in 22.07 wrt GCC 12. Backports for 21.11 are in progress, you may try with the last stable/21.11 branch. https://git.dpdk.org/dpdk-stable/log/?h=21.11 -- David Marchand
Re: Couple of build problems ( Fedora 36, DPDK 21.11.1 )
On Wed, Jul 20, 2022 at 4:59 PM Mark de Roussier wrote: > > Hello David, > > thanks for the idea, but I'm afraid that's not the case. I do have that > already, that is what is providing libmlx4 and libmlx5. But it does not > contain librte_common_mlx5, which is what I think is probably the source of > my problem. Well, that's what I have on my Fedora to build mlx drivers. Btw, librte_common_mlx5 is an internal DPDK driver. If you still see that this component is disabled after installing those headers via the devel packages, then maybe you did not reconfigure your build env. $ meson --reconfigure If this is not working, you'll have to look into /meson-logs/, there may be some useful info in those logs. -- David Marchand
Re: Couple of build problems ( Fedora 36, DPDK 21.11.1 )
On Wed, Jul 20, 2022 at 2:19 PM Mark de Roussier wrote: > Hi Stephanov, > > thanks for the quick reply ! Yeah, I noticed the libmlx5 complaint in the > log, but it wasn't useful because I didn't know where to look for libmlx5. > Thanks for the pointer ! Looks like Fedora hasn't included the > libibverbs-dev package in it's standard repo, so I'll have to go hunt for > it, but now I know what I'm looking for . > I think you are looking for rdma-core-devel. -- David Marchand
Re: skeleton code failing
On Wed, Jul 13, 2022 at 7:35 AM Lokesh Chakka wrote: > Would like to understand if I am missing something. I am new to this platform. > rte_eth_dev_count_avail is returning zero. > OS is Ubuntu 22.04. DPDK is latest version. > Cards are being detected by Linux. Ifconfig is showing the cards up. LED is > also glowing. Indeed, DPDK provides a userspace driver for some NetXtreme nics (which is net/bnxt). This userspace driver does not rely on the bnxt Linux kernel driver. IOW, this card being detecting and working with the Linux kernel does not automatically mean that this nic can work with DPDK. We need more info on your nic, first. Can you share the pci id of this nic (like running lspci -n -s $pci_address)? It should be a 14e4:. Then you can check this against what your dpdk application supports. If it is a statically linked application, you can run: $ dpdk-pmdinfo.py /path/to/your/application Else, if your application is dynamically linked against DPDK driver, you can run this command against the net/bnxt driver .so.22 (for 21.11 and later releases): $ dpdk-pmdinfo.py /path/to/your/dpdk/drivers/librte_net_bnxt.so.22 You should get a list of supported NetXtreme nics, like: [snipped some other drivers compiled in my application] PMD NAME: net_bnxt PMD HW SUPPORT: Broadcom Inc. and subsidiaries (14e4) : BCM5745X NetXtreme-E RDMA Virtual Function (1606) (All Subdevices) Broadcom Inc. and subsidiaries (14e4) : BCM5745X NetXtreme-E Ethernet Virtual Function (1609) (All Subdevices) Broadcom Inc. and subsidiaries (14e4) : BCM57454 NetXtreme-E 10Gb/25Gb/40Gb/50Gb/100Gb Ethernet (1614) (All Subdevices) Broadcom Inc. and subsidiaries (14e4) : NetXtreme-E RDMA Virtual Function (16c1) (All Subdevices) Broadcom Inc. and subsidiaries (14e4) : NetXtreme-C Ethernet Virtual Function (16cb) (All Subdevices) [snipped the rest] I hope you can find a () corresponding to your NIC. -- David Marchand
Re: dpdk address sanitizer
Hello, On Fri, Jun 17, 2022 at 6:08 AM Juan Pablo L. wrote: > > Hello, I am new to dpdk ... i would like to trace memory usage and detect > memory leaks, valgrind as well as address sanitizer (gcc) report some memory > loss at application end. For the life of me, i cannot figure it out ... i > just write a simple program that has the rte_eal_init + rte_eal_cleanup and i > get the following error (also tried helloworld from examples, with same > results): > > ==3399==ERROR: AddressSanitizer: stack-buffer-overflow on address > 0x7f6ca3efb480 at pc 0x7f6ca7162b61 bp 0x7f6ca3efb450 sp 0x7f6ca3efac00 > WRITE of size 24 at 0x7f6ca3efb480 thread T-1 > #0 0x7f6ca7162b60 in __interceptor_sigaltstack.part.0 > (/lib64/libasan.so.8+0x61b60) > #1 0x7f6ca71d9337 in __sanitizer::UnsetAlternateSignalStack() > (/lib64/libasan.so.8+0xd8337) > #2 0x7f6ca71c90f4 in __asan::AsanThread::Destroy() > (/lib64/libasan.so.8+0xc80f4) > #3 0x7f6ca679b000 in __GI___nptl_deallocate_tsd (/lib64/libc.so.6+0x8a000) > #4 0x7f6ca679dc9d in start_thread (/lib64/libc.so.6+0x8cc9d) > #5 0x7f6ca68235df in __GI___clone3 (/lib64/libc.so.6+0x1125df) > > Address 0x7f6ca3efb480 is a wild pointer inside of access range of size > 0x0018. > SUMMARY: AddressSanitizer: stack-buffer-overflow > (/lib64/libasan.so.8+0x61b60) in __interceptor_sigaltstack.part.0 > Shadow bytes around the buggy address: > 0x0fee147d7640: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 > 0x0fee147d7650: 00 00 00 00 00 00 00 00 00 06 f2 f2 f2 f2 00 00 > 0x0fee147d7660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d7670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d7680: 00 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 > =>0x0fee147d7690:[f3]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0fee147d76e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==3399==ABORTING > > I am not sure what I m doing wrong but it is very frustrating. On top of > that, I try other scenarios and see if I can just "ignore" that and still > detect other memory leaks but it does not work. I get memory from rte_malloc > and don't free it and I still get the above report only, I do not get any > report from the memory I leaked intentionally ... no difference what so ever > I tried the same with the helloworld example and I get the same results > I experienced the same issue recently on Fedora 36. I did not investigate. I think I waived this warning, by setting ASAN_OPTIONS="use_sigaltstack=0" in the environment. HTH. -- David Marchand
Re: Question about supported GPU supported NICs
Hello, On Mon, Apr 11, 2022 at 2:57 PM sak...@fujitsu.com wrote: > > In my understanding, GPUDirect RDMA is supported on Tesla and Quadro/RTX. > But following code only specifies Tesla. > Is there any reason to specify in the code? > > List in the code > https://github.com/DPDK/dpdk/blob/v22.03/drivers/gpu/cuda/cuda.c#L56-L71 > > GPUDirect RDMA > GPUDirect RDMA is available on both Tesla and Quadro GPUs. > https://docs.nvidia.com/cuda/gpudirect-rdma/index.html Cc: Elena + Thomas -- David Marchand
Re: Building DPDK with Meson/Ninja using ICC
On Sun, Nov 28, 2021 at 1:57 PM Leonid Bloch wrote: > I'm trying to build DPDK 19.11.8 with Meson/Ninja using ICC. When using > `make`, it's as simple as: `make T=x86_64-native-linuxapp-icc`. > So there are two questions: > > 1. How is the same achieved with DPDK 19.11.8 when using Meson/Ninja? > 2. Is the answer to (1) still the same in newer DPDK versions? > > I did not find anything about it in the documentation, except the > `--cross-file` flag for meson, but there appears to be no adequate > config file for this in `config/x86`. > > Can anyone please assist? To build in a directory called "x86_64-native-linuxapp-icc", please try: $ CC=icc meson setup x86_64-native-linuxapp-icc $ ninja-build -C x86_64-native-linuxapp-icc -- David Marchand
Re: Aboud DPDK Multi-Process
On Thu, Nov 4, 2021 at 9:21 AM 赖香武 <15310488...@163.com> wrote: > > Hello, I have a question about dpdk multi-process. After starting the primary > process and the secondary process, when the current primary process exits, > how does the secondary process become a new primary process to make the > program continue? Hope to get your answer, thank you！ Not sure why you need this, but DPDK won't do for you. The process type is decided once at DPDK init, and that is something that affects how your program behaves after. Switching type while running would break assumptions in the DPDK drivers and libraries. One thing that comes to mind, is that you could try to call rte_eal_cleanup() and call rte_eal_init() again. This is probably something that is not tested (so I'd expect issues, maybe leaks etc..). But then, you probably want to restart your process entirely. -- David Marchand
Re: Error while compiling dpdk 21.08 for arm64
On Fri, Oct 29, 2021 at 4:04 PM animesh tripathi wrote: > > Hi Team, > > I am trying to compile dpdk 21.08 for arm64, but I am getting the following > error while compiling. I am compiling dpdk 21.08 on arm64 platform only. > This is a known issue with some toolchains. See: https://bugs.dpdk.org/show_bug.cgi?id=697 If you don't need this driver, you can disable it by passing meson option -Ddisable_drivers=common/cnxk -- David Marchand
Re: DPDK 21.08 build failure with meson 0.60.0
Hello, On Tue, Oct 26, 2021 at 7:32 AM Nigel Kukard wrote: > > I'm wondering if anyone can help me figure out why this is happening? it > looks like it was when meson was upgraded to 0.60.0. We are aware of the issue. There were reports from other users and a bz has been created: https://bugs.dpdk.org/show_bug.cgi?id=836 A change is being worked on, to handle this change in meson. https://patchwork.dpdk.org/project/dpdk/patch/20211026193239.113745-1-dmitry.kozl...@gmail.com/ -- David Marchand
Re: mlx5 VF packet lost between rx_port_unicast_packets and rx_good_packets
On Wed, Oct 27, 2021 at 8:18 AM Yan, Xiaoping (NSB - CN/Hangzhou) wrote: > > Hi, > > I tried with dpdk 20.11-3 downloaded from > https://fast.dpdk.org/rel/dpdk-20.11.3.tar.xz > Problem still exist: > 1. there is packet loss with 2mpps (small packet), > 2. no counter for the dropped packet in NIC. For mlx maintainers. Thanks. -- David Marchand
Re: mlx5 VF packet lost between rx_port_unicast_packets and rx_good_packets
On Mon, Oct 18, 2021 at 11:28 AM Yan, Xiaoping (NSB - CN/Hangzhou) wrote: > I have cloned dpdk code from github > > [xiaopiya@fedora30 dpdk]$ git remote -v > origin https://github.com/DPDK/dpdk.git (fetch) > origin https://github.com/DPDK/dpdk.git (push) > > which tag should I use? > > Or do I have to download 20.11.3 from git.dpdk.org? > > Sorry, I don’t know the relation between https://github.com/DPDK and > git.dpdk.org? Github DPDK/dpdk repo is a replication of the main repo hosted on dpdk.org servers. The official git repos and releases tarballs are on dpdk.org servers. The list of official releases tarballs is at: http://core.dpdk.org/download/ The main repo git is at: https://git.dpdk.org/dpdk/ The LTS/stable releases repo git is at: https://git.dpdk.org/dpdk-stable/ -- David Marchand
Re: DPDK 20.11/CentOS7.9, first run -> *FAILED*
On Thu, Oct 14, 2021 at 1:37 PM Ruslan R. Laishev wrote: > Since > http://doc.dpdk.org/guides-16.04/linux_gsg/quick_start.html#linux-setup-script I am surprised to see you are using a 16.04 version. I recommend using the latest LTS, i.e. 20.11. For this version, the quick start guide is https://doc.dpdk.org/guides-20.11/linux_gsg/index.html > refer to nonexistent SETUP.SH, i walking over the docs an do steps to > unsure that DPDK is working at all after installation. > > So: > > > [root@sysman ~]# sudo modprobe uio_pci_generic > [ 1084.673269] Generic UIO driver for PCI 2.3 devices version: 0.01.0 > > [root@sysman ~]# sudo modprobe vfio-pci > [ 1118.429157] VFIO - User Level meta-driver version: 0.3 > > [root@sysman ~]# dpdk-devbind.py -s > > Network devices using kernel driver > === > :02:01.0 '82545EM Gigabit Ethernet Controller (Copper) 100f' > if=ens33 drv=e1000 unused=vfio-pci,uio_pci_generic *Active* > :02:05.0 '82545EM Gigabit Ethernet Controller (Copper) 100f' > if=ens37 drv=e1000 unused=vfio-pci,uio_pci_generic > :02:06.0 '82545EM Gigabit Ethernet Controller (Copper) 100f' > if=ens38 drv=e1000 unused=vfio-pci,uio_pci_generic > > [root@sysman ~]# dpdk-devbind.py --bind=vfio-pci ens37 > Error: bind failed for :02:05.0 - Cannot bind to driver vfio-pci > Error: unbind failed for :02:05.0 - Cannot open > /sys/bus/pci/drivers//unbind > > [ 1215.157980] vfio-pci: probe of :02:05.0 failed with error -22 > [ 1215.164317] vfio-pci: probe of :02:05.0 failed with error -22 If your server has a iommu, you probably did not configure it. If you don't have such hw, you need no-iommu support. https://doc.dpdk.org/guides-20.11/linux_gsg/linux_drivers.html#troubleshooting-vfio -- David Marchand
Re: [Pktgen] how to send pcap file in loop
Hi Marco, On Mon, Oct 11, 2021 at 8:36 AM Marco Faltelli wrote: > > I was wondering, how do you replay a pcap file forever in Pktgen? > I'm using pktgen 19.08 and I'm trying to replay a pcap file at line rate on > one interface. I'm using the '-s IFACE:file.pcap' option but the > application stops after repeating around 3 times the pcap trace. I've also > tried using a .cfg file with the 'pcap' option but with no success. Can you provide the full command line, configuration and logs? Cc: Keith (pktgen maintainer). -- David Marchand
Re: intel X550T dpdk support issue
On Mon, Oct 4, 2021 at 8:53 PM Satish Patel wrote: > > Folks, > > I am new to this nic series and just found a strange issue, i am sure > people are using this nic in production with dpdk. > > # ovs-vsctl add-port br-vlan dpdk-1 -- set Interface dpdk-1 type=dpdk > options:dpdk-devargs=:3b:00.1 > ovs-vsctl: Error detected while setting up 'dpdk-1': Error attaching > device ':3b:00.1' to DPDK. See ovs-vswitchd log for details. > ovs-vsctl: The default log directory is "/var/log/openvswitch". > > > 2021-10-04T13:20:05.751Z|00272|dpdk|ERR|EAL: Driver cannot attach the > device (:3b:00.1) > 2021-10-04T13:20:05.751Z|00273|dpdk|ERR|EAL: Failed to attach device > on primary process > 2021-10-04T13:20:05.751Z|00274|netdev_dpdk|WARN|Error attaching device > ':3b:00.1' to DPDK > 2021-10-04T13:20:05.751Z|00275|netdev|WARN|dpdk-1: could not set > configuration (Invalid argument) > 2021-10-04T13:20:05.751Z|00276|dpdk|ERR|Invalid port_id=32 Cc: ixgbe maintainer. Let's first check if this is a OVS issue. Can you run testpmd with this nic? -- David Marchand
Re: intel X550T dpdk support issue
On Mon, Oct 4, 2021 at 11:20 PM Satish Patel wrote: > > Is this my issue ? No. For this specific trace below, you are probably trying to attach a secondary process to a primary process (which was OVS iiuc) which does not have the same enabled DPDK libraries/drivers. Having the same dpdk components (from the same version) in both binaries is the only way for multiprocess to work: I'd recommend linking both your binaries against a built once and for all set of dpdk libraries. Besides, please note that the OVS does not support multiprocess. Issues had been reported in the past (like pdump secondary process crashing OVS). There is work atm in OVS that will make multiprocess disabled. > > # dpdk-proc-info > EAL: Detected 48 lcore(s) > EAL: Detected 2 NUMA nodes > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_4651_a967f74152a > EAL: Selected IOVA mode 'VA' > EAL: Probing VFIO support... > EAL: VFIO support initialized > EAL: Cannot initialize tailq: RTE_EVENT_RING > Tailq 0: qname:, tqh_first:(nil), tqh_last:0x14488 > Tailq 1: qname:, tqh_first:(nil), tqh_last:0x144b8 > Tailq 2: qname:, tqh_first:(nil), tqh_last:0x144e8 > Tailq 3: qname:, tqh_first:(nil), tqh_last:0x14518 > Tailq 4: qname:, tqh_first:(nil), tqh_last:0x14548 > Tailq 5: qname:, tqh_first:(nil), tqh_last:0x14578 > Tailq 6: qname:, tqh_first:(nil), tqh_last:0x145a8 > Tailq 7: qname:, tqh_first:(nil), tqh_last:0x145d8 > Tailq 8: qname:<>, tqh_first:(nil), tqh_last:(nil) > Tailq 9: qname:<>, tqh_first:(nil), tqh_last:(nil) > Tailq 10: qname:<>, tqh_first:(nil), tqh_last:(nil) > Tailq 11: qname:<>, tqh_first:(nil), tqh_last:(nil) -- David Marchand
Re: [dpdk-users] [DPDK 20.11] rte_eal_init() appear additional thread
On Tue, Aug 17, 2021 at 11:19 AM Dong, Shaojie (NSB - CN/Hangzhou)
wrote:
> I found the additional thread was created by following path on DPDK 20.11
> version
>
> rte_eal_init()->rte_telemetry_init()->telemetry_v2_init()->pthread_create()
>
> Only call pthread_create() function to create this additional thread and then
> sleep all the time
> DPDK code do not set this thread's name
> So it inherits the main thread's name
>
> Two threads with the same name are easy to confuse by business code
> Does DPDK code support its name change ?
>
> It was not worker/slave thread
telemetry threads are renamed since 5da7736f8c53 ("telemetry: set
socket listener thread name") (with a followup fix).
--
David Marchand
Re: [dpdk-users] Installation of latest DPDK on x86_64 machine
On Tue, Jul 6, 2021 at 2:26 PM Ashish Mishra wrote: > > Hi Members , > > I am trying to get DPDK installed on x86_64 mahine by following below > steps > git clone https://dpdk.org/git/dpdk > cd dpdk/ > meson -Dexamples=all build > cd build > ninja > ninja install > > a) Any input where should in find "igb_uio.ko" > > b) Even i tried modprobe igb_uio.ko , it didn't helped as i dont see >/usr/local/lib64/dpdk/drivers folder but i can see > /usr/local/lib64/dpdk/pmds-21.3/librte_* > > c) Basically , i wanted to install latest DPDK on my laptop and run an > testpmd >Is there any document where we can find the step's to build and run > testpmd >for the latest version of DPDK > > I am new to DPDK , hence will be helpful if community can share some > pointers Please, prefer vfio-pci over igb_uio. https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html#vfio If you don't have an IOMMU in your system (like you are simply testing dpdk, or running dpdk in a virtual machine with no vIOMMU), you can use the noiommu mode, but keep note that it is less secure. https://doc.dpdk.org/guides/linux_gsg/linux_drivers.html#vfio-no-iommu-mode -- David Marchand
Re: [dpdk-users] Changing rte_mbuf
On Wed, Jun 16, 2021 at 8:09 AM mohamad ali wrote: > Hi i want to change rte_mbuf struct and add some custom struct to it but > when i change it and compile again some error related to this line shows up. > RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) > OCTEONTX_FPAVF_BUF_OFFSET); > > What is the correct way to add struct to rte_mbuf ? The correct way is not to add anything to rte_mbuf :-). If your application needs some private space per mbuf, you should instead embed the rte_mbuf struct into a structure of yours. Create a mempool with a private size accounting for this and make sure to init this private space per object. -- David Marchand
Re: [dpdk-users] 82599ES 10-Gigabit NIC can't use timesync?
On Fri, Jun 11, 2021 at 10:34 AM Linyih Teng wrote: > > I'm trying to capture rx/tx timestamp using *rte_eth_timesync_rx/tx_read()* > functions but it always returns EINVAL. Does the* 82599ES* NIC(with > *igb_uio*) support the timesync function to capture Tx/Rx timestamp? Did you call rte_eth_timesync_enable() and pass a valid timespec ? I would take testpmd as a reference and check it works with RTE_LIBRTE_IEEE1588 enabled. Cc: ixgbe maintainer. -- David Marchand
Re: [dpdk-users] DPDK: Telemetry - Support for Array of dictionaries
On Mon, Jun 7, 2021 at 5:39 PM Prashanth Fernando wrote: > > We would like to understand does DPDK-20.11 or later support array of > dictionary in the telemetry library. Cc: this library maintainer. -- David Marchand
Re: [dpdk-users] How to address the error “MBUF: error setting mempool handler” seen with DPDK 20.11
On Mon, Jun 7, 2021 at 5:37 PM Prashanth Fernando wrote: > > Update: > Had few issues with DPDK 20.11 in Centos-7. > > > * Installing Mellanox libverbs somehow affects the cflags and ldflags > for dpdk libdpdk.pc > * pkg-config from the installed target was also incorrect. > > Manually updating libdpdk.pc to include the static libraries under > -Wl,--whole-archive and -Wl,--no-whole-archive This is a known issue with pkg-config 0.27. See: https://doc.dpdk.org/guides/linux_gsg/sys_reqs.html?highlight=pkg%20config#building-dpdk-applications -- David Marchand
Re: [dpdk-users] dpdk-20.11 and shared libraries
On Tue, Apr 20, 2021 at 6:25 PM Templin (US), Fred L wrote: > > Hi, I have put a lot of time into learning about dpdk-20.11 but I have not > yet found > documentation on how to use it with shared libraries. In dpdk-20.11, the > examples > are all built as "static" by default meaning that the entire kitchen sink of > all DPDK > libraries are linked in during the "ld" phase and the resulting binary is > huge. When > built as "static", the examples all appear to work fine as everything is > loaded by > default at runtime. > > When I build the examples as "shared", however, the story is completely > different. > Examples that run fine as "static" do not work at all when built as "shared". > It is > clear that somehow the build procedure is not giving adequate instructions to > the > loader so that all necessary libraries will be ready to go at runtime. > > I believe what needs to happen is that initialization code needs to be added > to the > example "main.c" modules to initialize functions that will be needed by lower > levels > but that are not being picked up on by the loader. But, I can find no > documentation > for how to do this. In my next message, I will send a code example of what I > have > tried so far. I suppose you are testing with a local build (i.e. a dpdk not installed system wide). Example with my build env: $ $HOME/builds/build-gcc-shared/examples/dpdk-helloworld --no-huge -m 512 --vdev net_null0 EAL: Detected 28 lcore(s) EAL: Detected 1 NUMA nodes EAL: Detected shared linkage of DPDK EAL: failed to parse device "net_null0" EAL: Unable to parse device 'net_null0' PANIC in main(): Cannot init EAL 5: [/home/dmarchan/builds/build-gcc-shared/examples/dpdk-helloworld() [0x40116e]] 4: [/usr/lib64/libc.so.6(__libc_start_main+0xf2) [0x7f7ece854082]] 3: [/home/dmarchan/builds/build-gcc-shared/examples/dpdk-helloworld() [0x4010b6]] 2: [/home/dmarchan/builds/build-gcc-shared/examples/../lib/librte_eal.so.21(__rte_panic+0xbe) [0x7f7eceb828cc]] 1: [/home/dmarchan/builds/build-gcc-shared/examples/../lib/librte_eal.so.21(rte_dump_stack+0x1b) [0x7f7eceba26cb]] Aborted (core dumped) You have several solutions. You can simply install dpdk system wide. Or, try to pass -d in EAL cmdline options. $ LD_LIBRARY_PATH=$HOME/builds/build-gcc-shared/install/usr/local/lib64 $HOME/builds/build-gcc-shared/examples/dpdk-helloworld --no-huge -m 512 -d $HOME/builds/build-gcc-shared/install/usr/local/lib64/dpdk/pmds-21.2/librte_net_null.so --vdev net_null0 EAL: Detected 28 lcore(s) EAL: Detected 1 NUMA nodes EAL: Detected shared linkage of DPDK EAL: Multi-process socket /run/user/1001/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: VFIO support initialized TELEMETRY: No legacy callbacks, legacy socket not created hello from core 1 hello from core 2 hello from core 3 hello from core 4 hello from core 5 hello from core 6 hello from core 7 hello from core 8 hello from core 9 hello from core 10 hello from core 11 hello from core 12 hello from core 13 hello from core 14 hello from core 15 hello from core 16 hello from core 17 hello from core 18 hello from core 19 hello from core 20 hello from core 21 hello from core 22 hello from core 23 hello from core 24 hello from core 25 hello from core 26 hello from core 27 hello from core 0 Or you can also pass a directory to this option and EAL will try to load any driver in this directory. -- David Marchand
Re: [dpdk-users] Help needed to interface to new device
On Wed, Mar 24, 2021 at 1:27 PM David Aldrich wrote: > > If you are talking about a XX710/N3000 device, I think its support was > > added in 19.05. > > No 18.11 driver supports this nic, you can probably have a try with > > the next LTS release 19.11, or the latest LTS which is 20.11. > > Thanks for your reply. Yes, I am talking about the Intel N3000 FPGA > accelerator card. Forgive my ignorance, does that imply a XX710 device? > > I rebuilt using DPDK v 19.11.7 but got the same result: i.e. > rte_eth_dev_count_avail() returns 0. > > I can try using DPDK 20.11 but that will take a little while as I need to > adjust to the new meson build environment. Surprised this does not work with v19.11. I'll let Intel developers/maintainers sort this out. -- David Marchand
Re: [dpdk-users] Problem in dpdk mpool initialization in dpdk20.11
lrte_eal -lrte_telemetry -lrte_kvargs -lm -ldl -lnuma -lpcap -libverbs -lpthread -lz You can notice the static libraries are not protected by the --whole-archive / --no-whole-archive options. The linker won't embed the unreferenced dpdk libraries in the final binary. There is no clean fix (you could try to reorganise cflags but this is fragile), unless updating pkg-config. -- David Marchand
Re: [dpdk-users] Problem in dpdk mpool initialization in dpdk20.11
On Mon, Mar 8, 2021 at 9:42 AM Pinak Tripathy wrote:
> I am porting the application from dpdk 17.11 to dpdk 20.11
> Application uses centos7.9 and melanox 5.2.2 PMD
>
> Below api call works fine in dpdk17.11 but fails in dpdk20.11
>
> rte_pktmbuf_pool_create ("mbuf_pool_0", (4096 * 64 * 16 - 1), 512, 0,
> RTE_MBUF_DEFAULT_BUF_SIZE) fails with error no 22 (EINVAL)
> -MBUF: error setting mempool handler
> -PANIC in app_init_mbuf_pools():
> -Cannot create mbuf pool on socket 0 (errno=22)
>
> On adding debug trace found that rte_mempool_ops_table.num_ops =0.
>
> Not sure what is causing this issue. Can you please point out likely cause of
> this?
This is likely a problem with loading mempool drivers.
Does adding "-d /path/to/librte_mempool_ring.so" to your EAL options
help with this issue?
--
David Marchand
Re: [dpdk-users] DPDK program huge core file size
On Wed, Feb 24, 2021 at 5:00 AM Li Feng wrote: > > I think you should update your dpdk to the latest. > I have fixed this issue some months ago. > > d72e4042c - mem: exclude unused memory from core dump No need to go to the latest release, this commit has been backported to 19.11 recently. http://git.dpdk.org/dpdk-stable/commit/?h=19.11=d3ceba92eff783d2c995387e5ed8509045578748 You can wait for the next 19.11.x release. -- David Marchand
Re: [dpdk-users] Integration from Dpdk18.05 to Dpdk19.11 - rte_timer_subsystem_init(void)
On Sun, Jan 17, 2021 at 11:04 PM Li, Jiu (NSB - CN/Hangzhou) wrote: > > Hello! Dpdk experts, > > On Dpdk 18.05, void rte_timer_subsystem_init(void) > On Dpdk 19.11, intrte_timer_subsystem_init(void) implementation changed, > which will return 0, -EALREADY or -ENOMEM; > > There is still have dpdk "process" mode (instead of pdkd thread mode) > deployment in my side. > Can I have a question? > > If rte_timer_subsystem_init() is called one time is enough? > After rte_timer_subsystem_init() called with return 0 by one process , then > other processes are able to use "rte timer" service without issue, right? > Copied timer library maintainers. -- David Marchand
Re: [dpdk-users] A compilation problem on arm64
On Sun, Jan 17, 2021 at 11:04 PM LemmyHuang wrote: > > Dear Concerns, > > > I have a compilation problem on arm64. > My environment is dpdk-19.11, gcc-9.3.1 and kernel-5.10.0-0.0.0.7.aarch64. > The errors are as follows: > > > ... > CC [M] > /home/abuild/rpmbuild/BUILD/dpdk-19.11/arm64-armv8a-linux-gcc/build/kernel/linux/kni/kni_misc.o > [0m > CC [M] > /home/abuild/rpmbuild/BUILD/dpdk-19.11/arm64-armv8a-linux-gcc/build/kernel/linux/kni/kni_net.o > [0m > LD librte_common_octeontx2.so.20.0 [0m > INSTALL-LIB librte_common_octeontx2.so.20.0 [0m > == Build drivers/bus [0m > In file included from ./include/linux/atomic.h:7, [0m > from > ./include/asm-generic/bitops/atomic.h:5, [0m > from > ./arch/arm64/include/asm/bitops.h:26, [0m > from > ./include/linux/bitops.h:29, [0m > from > ./include/linux/kernel.h:12, [0m > from > ./include/linux/list.h:9, [0m > from > ./include/linux/rculist.h:10, [0m > from > ./include/linux/pid.h:5, [0m > from > ./include/linux/sched.h:14, [0m > from > ./include/linux/ratelimit.h:6, [0m > from > ./include/linux/dev_printk.h:16, [0m > from > ./include/linux/device.h:15, [0m > from > /home/abuild/rpmbuild/BUILD/dpdk-19.11/arm64-armv8a-linux-gcc/build/kernel/linux/igb_uio/igb_uio.c:8: > [0m > ./include/linux/atomic-arch-fallback.h: In function > 'igbuio_pci_open': [0m > ./arch/arm64/include/asm/atomic.h:20:20: error: inlining failed in > call to 'arch_atomic_sub.constprop': --param max-inline-insns-single-O2 limit > reached [-Werror=inline] [0m > 20 | static inline void arch_##op(int i, atomic_t > *v) \ [0m >| > ^ [0m > ./arch/arm64/include/asm/atomic.h:30:1: note: in expansion of macro > 'ATOMIC_OP' [0m > 30 | ATOMIC_OP(atomic_sub) [0m >| ^ [0m > In file included from ./include/linux/atomic.h:81, [0m > from > ./include/asm-generic/bitops/atomic.h:5, [0m > from > ./arch/arm64/include/asm/bitops.h:26, [0m > from > ./include/linux/bitops.h:29, [0m > from > ./include/linux/kernel.h:12, [0m > from > ./include/linux/list.h:9, [0m > from > ./include/linux/rculist.h:10, [0m > from > ./include/linux/pid.h:5, [0m > from > ./include/linux/sched.h:14, [0m > from > ./include/linux/ratelimit.h:6, [0m > from > ./include/linux/dev_printk.h:16, [0m > from > ./include/linux/device.h:15, [0m > from > /home/abuild/rpmbuild/BUILD/dpdk-19.11/arm64-armv8a-linux-gcc/build/kernel/linux/igb_uio/igb_uio.c:8: > [0m > ./include/linux/atomic-arch-fallback.h:441:2: note: called from here > [0m > 441 | arch_atomic_sub(1, v); [0m >| ^ [0m > cc1: all warnings being treated as errors [0m > make[6]: *** [scripts/Makefile.build:279: > /home/abuild/rpmbuild/BUILD/dpdk-19.11/arm64-armv8a-linux-gcc/build/kernel/linux/igb_uio/igb_uio.o] > Error 1 [0m > make[5]: *** [Makefile:1805: > /home/abuild/rpmbuild/BUILD/dpdk-19.11/arm64-armv8a-linux-gcc/build/kernel/linux/igb_uio] > Error 2 [0m > make[4]: *** > [/home/abuild/rpmbuild/BUILD/dpdk-19.11/mk/rte.module.mk:51: igb_uio.ko] > Error 2 [0m > make[3]: *** > [/home/abuild/rpmbuild/BUILD/dpdk-19.11/mk/rte.subdir.mk:37: igb_uio] Error 2 > [0m > make[3]: *** Waiting for unfinished jobs [0m > ... This is hard to read, please paste raw outputs. This error does not ring a bell, this is probably kernel/arch specific. I copied Luca who maintains 19.11. On the other hand, rather than fixing igb_uio build, why don't you use vfio-pci? -- David Marchand
Re: [dpdk-users] Help with error: *** Did not find any ports to use ***
On Mon, Dec 14, 2020 at 8:46 PM Krishnamurthy Srinivasan
wrote:
>
> I have seen that this error has been brought up before. However, the
> solutions discussed did not help resolve the error. I would appreciate any
> help.
>
> I am running DPDK version 20.11 with Pktgen 3.7.2 on Ubuntu 20.04/K8s. My
> server has Intel Ethernet Controller X710 for 10GbE.
>
> Here, I have configured the pod with one interface with igb-uio driver.
> The behavior is the same if I try pci-vfio DPDK driver. My kubectl
> description shows the network config to be OK:
>
[snip]
>
> root@master-01:~# /opt/dpdk-stable-19.11.3/usertools/dpdk-devbind.py -s |
> more
>
> Network devices using DPDK-compatible driver
>
> :41:0a.0 'Ethernet Virtual Function 700 Series 154c' drv=vfio-pci
> unused=iavf,igb_uio
> :41:0a.1 'Ethernet Virtual Function 700 Series 154c' drv=vfio-pci
> unused=iavf,igb_uio
>
> :41:0a.5 'Ethernet Virtual Function 700 Series 154c' drv=igb_uio
> unused=iavf,vfio-pci
>
Afaics, device 0x8086 / 0x154c is known by the common IAVF code base,
but it is associated with no PCI driver in DPDK.
$ git grep -w IAVF_DEV_ID_VF v20.11 --
v20.11:drivers/common/iavf/iavf_common.c: case IAVF_DEV_ID_VF:
v20.11:drivers/common/iavf/iavf_devids.h:#define IAVF_DEV_ID_VF
0x154C
Copying i40e and iavf maintainers, for further guidance.
--
David Marchand
Re: [dpdk-users] [dpdk-dev] 【meson build fail for octeontx2】
ODES’
> TIM_ARM_TMO_FASTPATH_MODES
> ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://bugzilla.redhat.com/bugzilla> for instructions.
> {standard input}: Assembler messages:
> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc
> directive
> Preprocessed source stored into /tmp/cchw0Ftu.out file, please attach this to
> your bugreport.
> [2056/2298] Compiling C object
> drivers/libtmp_rte_event_octeontx2.a.p/event_octeontx2_otx2_worker_dual.c.o
> ninja: build stopped: subcommand failed.
>
> The gcc version is:
> [root@centos-C3 dpdk-next-net]# gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-unknown-linux-gnu/10.1.0/lto-wrapper
> Target: aarch64-unknown-linux-gnu
> Configured with: ./configure --disable-multilib --enable-languages=c,c++
> --with-gmp=/usr/local/gmp-5.1.3 --with-mpfr=/usr/local/mpfr-4.0.2
> --with-mpc=/usr/local/mpc-1.1.0
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.1.0 (GCC)
>
> the OS types is centos
> Linux centos-C3 5.6.0-rc5+ #1 SMP PREEMPT Wed Oct 21 16:32:46 HKT 2020
> aarch64 aarch64 aarch64 GNU/Linux
>
> Do you have any idea about above?
This is a compiler bug.
Do you reproduce this with different versions of gcc? Like the one
coming with the Centos distribution?
--
David Marchand
Re: [dpdk-users] Error while building DPDK version 19.11 over latest kernel version
On Fri, Oct 2, 2020 at 9:06 AM Klei rama wrote: > I am trying to build DPDK version 19.11 in my ubuntu machine (18.04) with > the latest kernel version 5.9. It gives me an error while I try to build > it. The error is when I try to build linux/kni module. > The error looks something like this: > > *dpdk/kernel/linux/kni/kni_dev.h:104:30:* *error: *passing argument 1 of ‘ > *get_user_pages_remote*’ from incompatible pointer type [ > *-Werror=incompatible-pointer-types*] There was a patch merged recently in the main branch. See: https://git.dpdk.org/dpdk/commit/?id=87efaea6376c -- David Marchand
Re: [dpdk-users] [dpdk-dev] Compilation failure with DPDK 18.11.1 (LTS)
On Wed, May 29, 2019 at 10:38 AM adabala, raghuram < raghuram.adab...@dell.com> wrote: > Hello, > I cannot seem to find the definition of ret_dev_cmp_t in any of the > headers I have on my Linux host. > I have installed the following rpms on my host. > Could you please help figure out what other rpm(s) I need ?. > Regards, > Raghu. > > dpdk-16.11.8-6.8.1.x86_64 > dpdk-kmp-default-16.11.8_k4.4.162_78-6.8.1.x86_64 > dpdk-devel-16.11.8-6.8.1.x86_64 > > +++ > CC lib/env_dpdk/env.o > In file included from env_internal.h:44:0, > from env.c:36: > /raghu/spdk/dpdk/lib/librte_eal/common/include/rte_bus.h:121:58: error: > unknown type name 'rte_dev_cmp_t' > (*rte_bus_find_device_t)(const struct rte_device *start, rte_dev_cmp_t cmp, > ^ > /raghu/spdk/dpdk/lib/librte_eal/common/include/rte_bus.h:237:2: error: > unknown type name 'rte_bus_find_device_t' > rte_bus_find_device_t find_device; /**< Find a device on the bus */ > ^ > /raghu/spdk/dpdk/lib/librte_eal/common/include/rte_bus.h:243:2: error: > unknown type name 'rte_dev_iterate_t' > rte_dev_iterate_t dev_iterate; /**< Device iterator. */ > ^ > In file included from env.c:36:0: > env_internal.h:46:25: fatal error: rte_bus_pci.h: No such file or directory > #include > ^ > compilation terminated. > +++ > Not sure what your problem is, but I can see the definition in rte_dev.h in official v18.11.1 tag. v18.11.1:lib/librte_eal/common/include/rte_dev.h:typedef int (*rte_dev_cmp_t)(const struct rte_device *dev, const void *data); -- David Marchand
