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