Thanks Rushil, I tested with 23.11 and everything is good now. Out of interest, what determines the queue format on the device? Is there a way to change the queue format such that 22.11 where gve support first appear could be used? Thanks, Peter. ________________________________ From: Rushil Gupta Sent: 29 October 2024 21:14 To: Peter Morrow Cc: users@dpdk.org ; joshwash@google.com ; jeroendb@google.com ; jungeng.guo@intel.com Subject: Re: gve queue format on dpdk 22.11 This email originated outside of your organization, do not visit any link, open any attachments or provide any sensitive information unless you recognize the sender and are certain the content can be trusted Hi Peter DQO_RDA is supported 23.07 onwards. On Tue, Oct 29, 2024 at 10:09 AM Peter Morrow > wrote: Hi Folks, Reading the docs for the the 22.11 release it clearly states that the DQO_RDA queue format is not yet supported: https://doc.dpdk.org/guides-22.11/nics/gve.html I'm attempting to bring up our software router on GCP (VM instance type c4-standard-8) where we are currently using dpdk 22.11 (via debian, with a 6.1.0-26-amd64 kernel), given the lack of support for DQO_RDA I see the following expected messages when I start vpp (our dpdk application): Oct 29 11:11:59 gcpt2 vnet[1919]: dpdk: gve_adminq_describe_device(): Driver is running with DQO RDA queue format. Oct 29 11:11:59 gcpt2 vnet[1919]: dpdk: gve_adminq_describe_device(): MAC addr: 42:01:0A:07:00:0F Oct 29 11:11:59 gcpt2 vnet[1919]: dpdk: gve_init_priv(): Max TX queues 2, Max RX queues 2 Oct 29 11:11:59 gcpt2 vnet[1919]: dpdk: gve_dev_init(): DQO_RDA is not implemented and will be added in the future As a result vpp sefaults shortly after: (gdb) bt #0 gve_adminq_create_tx_queue (queue_index=0, priv=0xbc03a59c0) at ../drivers/net/gve/base/gve_adminq.c:502 #1 gve_adminq_create_tx_queues (priv=0xbc03a59c0, num_queues=2) at ../drivers/net/gve/base/gve_adminq.c:516 #2 0x00007ffda6c9c5d6 in gve_dev_start (dev=0x7ffe1f4f7240 ) at ../drivers/net/gve/gve_ethdev.c:181 #3 0x00007ffe1f489b6a in rte_eth_dev_start () from /lib/x86_64-linux-gnu/librte_ethdev.so.23 #4 0x00007ffff584aa14 in dpdk_device_start (xd=xd@entry=0x7ffe204fbac0) at ./src/plugins/dpdk/device/common.c:393 #5 0x00007ffff584c598 in dpdk_interface_admin_up_down (vnm=, hw_if_index=, flags=) at ./src/plugins/dpdk/device/device.c:485 #6 0x00007ffff6ab3ccd in vnet_sw_interface_set_flags_helper (vnm=vnm@entry=0x7ffff7f6b660 , sw_if_index=, flags=VNET_SW_INTERFACE_FLAG_ADMIN_UP, helper_flags=0, helper_flags@entry=VNET_INTERFACE_SET_FLAGS_HELPER_WANT_REDISTRIBUTE) at ./src/vnet/interface.c:545 #7 0x00007ffff6ab489f in vnet_sw_interface_set_flags (vnm=vnm@entry=0x7ffff7f6b660 , sw_if_index=, flags=) at ./src/vnet/interface.c:601 #8 0x00007ffff6accee9 in vl_api_sw_interface_set_flags_t_handler (mp=0x7ffe3f241ff8) at ./src/vnet/interface_api.c:100 #9 0x00007ffff7fa6e0d in msg_handler_internal (free_it=0, do_it=1, trace_it=, msg_len=, the_msg=0x7ffe3f241ff8, am=0x7ffff7fb8f40 ) at ./src/vlibapi/api_shared.c:580 #10 vl_msg_api_handler_no_free (the_msg=0x7ffe3f241ff8, msg_len=) at ./src/vlibapi/api_shared.c:652 #11 0x00007ffff7f8ed7f in vl_socket_process_api_msg (rp=, input_v=) at ./src/vlibmemory/socket_api.c:208 #12 0x00007ffff7f978d3 in vl_api_clnt_process (vm=, node=, f=) at ./src/vlibmemory/memclnt_api.c:429 #13 0x00007ffff6853966 in vlib_process_bootstrap (_a=) at ./src/vlib/main.c:1223 #14 0x00007ffff67ba03c in clib_calljmp () at /usr/src/packages/BUILD/src/vppinfra/longjmp.S:123 #15 0x00007ffe1edfcd90 in ?? () #16 0x00007ffff6855054 in vlib_process_startup (f=0x0, p=0x7ffe2078f780, vm=0x7ffe1fa007c0) at ./src/vlib/main.c:1248 #17 dispatch_process (vm=0x7ffe1fa007c0, p=, last_time_stamp=, f=0x0) at ./src/vlib/main.c:1304 #18 0x0000000000000000 in ?? () (gdb) The segfault occurs due to the complq pointer here being NULL: cmd.create_tx_queue.tx_comp_ring_addr = cpu_to_be64(txq->complq->tx_ring_phys_addr); It may be possible to upgrade to a more recent version of dpdk which should help me progress, though before I do that I wondered if there is any other way to make progress here? Specifically, is there a way to force a different queue format in the device? This is a c4-standard-8 VM running in GCE. Thanks! Peter.