Expectations of an RX mbuf when using virtio PMD

Expectations of an RX mbuf when using virtio PMD

[Patrick Mahan]

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

Re: Expectations of an RX mbuf when using virtio PMD

[Oleksandr Nahnybida]

[-- Attachment #1: Type: text/plain, Size: 3036 bytes --]

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 AM Patrick Mahan <mahan@mahan.org> 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
>

[-- Attachment #2: Type: text/html, Size: 3500 bytes --]

Re: Expectations of an RX mbuf when using virtio PMD

[Patrick Mahan]

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 <mahan@mahan.org 
> <mailto:mahan@mahan.org>> 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
> 

Re: Expectations of an RX mbuf when using virtio PMD

[Stephen Hemminger]

On Sat, 7 Dec 2024 21:10:39 -0800
Patrick Mahan <mahan@mahan.org> wrote:

> 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.

Most code doesn't use ptype, and reading the packet data to determine the
type would slow down tests like basic forwarding