<div dir="ltr">Hello Patrick, You can use rte_net_get_ptype function directly if packet_type is RTE_PTYPE_UNKNOWN. <div>Whether the packet_type value is set is PMD/NIC dependent. </div><div>i40e does this at the hardware level, virtio does this in software with rte_net_get_ptype and only in the specific case. Best regards, Oleksandr</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 8, 2024 at 12:49 AM Patrick Mahan <<a href="mailto:mahan@mahan.org" target="_blank">mahan@mahan.org</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello All, Specifics: DPDK Version: dpdk-stable-18.11.11 Linux Kernel: 4.19.87 Intel 64-bit architecture I am working on a code to support our socket based processes that need to run on our DPDK-enabled platform. I am using the virtio_user exception path mechanism to support this and initial tests seem fine. However, I am seeing issues when we receive the packet from the virtio port, that the packet_type field is not set. In my code, I have setup my physical PMD (i40e) as etherdev 0 and etherdev 1 and have setup the virtual side with virtio as etherdev 2 and etherdev 3. I am pairing this as etherdev 0 (physical) to etherdev 2 (virtio_user0) and etherdev 1 (physical) to etherdev 3 (virtio_user1). I am using the EAL function `rte_eal_hotplug_add()` as suggested in the documentation. I have added code in my dispatch function to generate a syslog(3) to print the contents of the packet_type field in the received mbuf. I then generate traffic to etherdev 1 from connected host and I am seeing the following: The inbound packet log shows - Dec 7 21:24:45 2024 pmahan-dpdk pktdaemon-eal[27614]: CPU 2 TID 1140607382984128: [pktdaemon.NOTICE]: pkt_dpdk::switch_q_pkts()[2][1=>3][Q=0]: mbuf packet type is 0x00000091 So etherdev 1 packet (physical) has packet_type of 0x91 which translates to RTE_PTYPE_L2_ETHER RTE_PTYPE_L3_IPV4_EXT_UNKNOWN Which has been my experience for receiving packets from the physical PMD. However, now that I have added the virtio port, the return packet does not seemed to have this value set - Dec 7 21:24:45 2024 pmahan-dpdk pktdaemon-eal[27614]: CPU 2 TID 1140607382984128: [pktdaemon.NOTICE]: pkt_dpdk::switch_q_pkts()[2][3=>1][Q=0]: mbuf packet type is 0x00000000 I have looked into virtio PMD code and see that there is a function to fill in the packet type called `virtio_rx_offload()` but it is only called if the hardware associated with the virtual queue supports offloading and then only if the `virtio_net_hdr` has no flags or its `gso_type` is not GSO_NONE. If I ignore the flags and just inject the packets directly, everything seems to work, but I have internal code that needs to know the basic ethernet type as well as the L3 options and I was hoping to rely on the packet_type of the mbuf instead of having to do packet groveling. Is this an "as designed" or am I missing something in the configuration? Thanks for any pointers, Patrick </blockquote></div>