From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id AB0CA45E46 for ; Sun, 8 Dec 2024 06:10:44 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34682402BC; Sun, 8 Dec 2024 06:10:44 +0100 (CET) Received: from ns.mahan.org (unknown [23.24.207.145]) by mails.dpdk.org (Postfix) with ESMTP id 9C7D8402BB for ; Sun, 8 Dec 2024 06:10:42 +0100 (CET) Received: from [192.168.1.53] (crowTrobot [23.24.207.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ns.mahan.org (Postfix) with ESMTPSA id 2C61D1DD92; Sat, 7 Dec 2024 21:10:42 -0800 (PST) Message-ID: <256fdd95-68a1-4fb8-972b-f3d08935ed0e@mahan.org> Date: Sat, 7 Dec 2024 21:10:39 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Expectations of an RX mbuf when using virtio PMD Content-Language: en-US To: Oleksandr Nahnybida Cc: users@dpdk.org References: From: Patrick Mahan In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org On 12/7/24 3:58 PM, Oleksandr Nahnybida wrote: > Hello Patrick, > > You can use rte_net_get_ptype function directly if packet_type is RTE_PTYPE_UNKNOWN. > Whether the packet_type value is set is PMD/NIC dependent. > i40e does this at the hardware level, virtio does this in software with > rte_net_get_ptype and only in the specific case. > Thanks for the suggestion, I guess I was spoiled by the PMD setting it for me that I expected it was a basic function of the PMD. Thanks, Patrick > Best regards, > Oleksandr > > On Sun, Dec 8, 2024 at 12:49 AM Patrick Mahan > wrote: > > 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 >