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 524DB45E0B for ; Sun, 8 Dec 2024 00:58:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA238402BC; Sun, 8 Dec 2024 00:58:57 +0100 (CET) Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by mails.dpdk.org (Postfix) with ESMTP id 82DAC402BB for ; Sun, 8 Dec 2024 00:58:56 +0100 (CET) Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-2ee3206466aso3855328a91.1 for ; Sat, 07 Dec 2024 15:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interfacemasters.com; s=google; t=1733615935; x=1734220735; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IJbxldSNfjpdEn7IUIj1rvrrQ7/GpTtt6Uxwk7dXdnM=; b=PE1TLYI0MuBZuoY1ALIdVCVvUWJ9gmISFhcu+v7vxg9O/FD629DmYVa1geC+pld0PV 5u04Yd+Kl0irBxS2/j48ai9darCyQfk64Ls8VxqLp6scgxkn9/qVmIMWofE/0mIAz3h+ FeS2hdxScu2IqAglSc7RlN8SlOWopxVNFp5rQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733615935; x=1734220735; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IJbxldSNfjpdEn7IUIj1rvrrQ7/GpTtt6Uxwk7dXdnM=; b=MWyXL2JgW7Y5TXLHb1/uyhUkvV5sP4gtmtQreYIEOirAjaJbc1CSD8drYUxB1wQbcI V7h51xT2oqMEsW10Oe18cM3UddFZgp17oGnP+uy9UJsX5cyHxc7bl8n7qqpiUO02zTzf ENMMGQSLZniIsi3QzaEeSzjeTo7nQpNUpPQps8GJotGwk9ssD10sfSoq2mq1UTU5Nez7 I57DpCNSWvG/OZj1Uq07N4kJug/RMBLkOrG9k041LXRrAkxKq1QoePxUBAdr1CNn/QcV Z6r641VqDmF4DrZY+VyylowK2AZR/0ip71xdsl3R5E5GZJorhZiznhrvsw+JYVDQxfOE SvdQ== X-Gm-Message-State: AOJu0YzrKva/H1Tc51SI1LSnTqhJ0ruL0x1sKRBW9kRHAUPtBqjIBwI1 v5eRsJkYL8Y1ckz+jQ9GzBMp7qSj4Y7tKmdOlEKlxwemI19ErMUtI1cHMvRTIWWHsxkp1V4gMZZ KK7NYjs8d2GT5HbTGNsatB+QAtD3DB9woC/OJbgFsDy/EnhSyKWo= X-Gm-Gg: ASbGncukB/Wd3rBt4N5gHzvXdvUUAsqiR4o5aXVjZ4Kwz/CnAz7abkEhvaBghbXv7I0 HdFGlPTSmnFJIMPHuE9hm6A3c1cJRP4LJVQ== X-Google-Smtp-Source: AGHT+IE6FXjdStVWdnNT3/M5FlRsWJY4aImq/s4y7zHhRHCra9HBpSbNmc9pLzrBiWom/eJkMwF0Qjxmgb208ppK584= X-Received: by 2002:a17:90b:3a86:b0:2ee:c30f:33c9 with SMTP id 98e67ed59e1d1-2ef68e13ed3mr12922922a91.14.1733615935345; Sat, 07 Dec 2024 15:58:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Oleksandr Nahnybida Date: Sun, 8 Dec 2024 01:58:29 +0200 Message-ID: Subject: Re: Expectations of an RX mbuf when using virtio PMD To: Patrick Mahan Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="00000000000000f1b90628b6ea1a" 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 --00000000000000f1b90628b6ea1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. Best regards, Oleksandr On Sun, Dec 8, 2024 at 12:49=E2=80=AFAM Patrick Mahan wro= te: > 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 etherde= v > 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) a= nd > 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 prin= t > 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=3D>3][Q=3D0]: > 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 no= t > 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=3D>1][Q=3D0]: > 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 > --00000000000000f1b90628b6ea1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Patrick,

You can use=C2=A0rte_net_get_ptype f= unction directly if packet_type is RTE_PTYPE_UNKNOWN.=C2=A0
Whether the= packet_type=C2=A0value is set is PMD/NIC dependent.=C2=A0
i40e d= oes this at the hardware=C2=A0level, virtio does this in software with rte_= net_get_ptype and only in the specific case.

Best regards,
Oleksa= ndr

On Sun, Dec 8, 2024 at 12:49=E2=80=AFAM Patrick Mahan <mahan@mahan.org> wrote= :
Hello All,

Specifics:
=C2=A0 =C2=A0 DPDK Version: dpdk-stable-18.11.11
=C2=A0 =C2=A0 Linux Kernel: 4.19.87
=C2=A0 =C2=A0 Intel 64-bit architecture

I am working on a code to support our socket based processes that need to r= un on
our DPDK-enabled platform.=C2=A0 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=C2=A0 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 t= he
following:

The inbound packet log shows -

Dec=C2=A0 7 21:24:45 2024 pmahan-dpdk pktdaemon-eal[27614]: CPU 2 TID
1140607382984128: [pktdaemon.NOTICE]: pkt_dpdk::switch_q_pkts()[2][1=3D>= 3][Q=3D0]:
mbuf packet type is 0x00000091

So etherdev 1 packet (physical) has packet_type of 0x91 which translates to=
=C2=A0 =C2=A0 RTE_PTYPE_L2_ETHER
=C2=A0 =C2=A0 RTE_PTYPE_L3_IPV4_EXT_UNKNOWN

Which has been my experience for receiving packets from the physical PMD. <= br> However, now that I have added the virtio port, the return packet does not = seemed
to have this value set -

Dec=C2=A0 7 21:24:45 2024 pmahan-dpdk pktdaemon-eal[27614]: CPU 2 TID
1140607382984128: [pktdaemon.NOTICE]: pkt_dpdk::switch_q_pkts()[2][3=3D>= 1][Q=3D0]:
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 <= br> hardware associated with the virtual queue supports offloading and then onl= y 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 seem= s to
work, but I have internal code that needs to know the basic ethernet type a= s well
as the L3 options and I was hoping to rely on the packet_type of the mbuf i= nstead
of having to do packet groveling.

Is this an "as designed" or am I missing something in the configu= ration?

Thanks for any pointers,

Patrick
--00000000000000f1b90628b6ea1a--