[dpdk-dev] Possible Bug: DPDK 16.04 Empty packet_type

[Tan, Jianfeng]

Hi,


On 7/6/2016 3:54 AM, Craig, Chris A. wrote:
> We recently upgraded our environment to the 16.04 version of DPDK on a 14.04 installation of Ubuntu. After upgrading, we noticed our code was behaving oddly. After further inspection, we discovered the `packet_type` attribute of the mbuf is always 0. We had previously used it to detect L2 protocols for further processing and confirmed our suspicions by seeing the correct bit flags set in dpdk-2.2.0. In addition, the same behavior is observed after upgrading the machine to 16.04. Attached and in-line are a small write up of the observed issue. Has anyone else observed this behavior? Is it expected?


This could be related to this commit:

    commit c8f9e99c7abdd4b2e4aae09313ba8f12df263a2a
    Author: Jianfeng Tan <jianfeng.tan at intel.com>
    Date:   Fri Mar 25 08:47:47 2016 +0800

         config: enable i40e vector driver

         Previously, vector driver is not the first (default) choice for
    i40e,
         as it cannot fill packet type info for l3fwd to work well. Now
    there
         is an option for l3fwd to analysis packet type softly. So enable it
         by default.

So could you please have a check what Rx/Tx functions are you using? 
I40e vector driver does not support setting packet type.

Thanks,
Jianfeng


> ======
> DPDK 16.04 Bug
> CPU: Intel(R) Xeon(R) CPU E5-2687W v3
> NICs: (2) Intel Corporation Ethernet 10G 2P X710 Adapter
> OS: Ubuntu 14.04 and 16.04
> Kernel: 3.16.0-60-generic (x84 64)
> DPDK: 16.04
> Network devices using DPDK-compatible driver
> ============================================
> 0000:01:00.1 ’Ethernet 10G 2P X710 Adapter’ drv=igb_uio unused=
> 0000:01:00.2 ’Ethernet 10G 2P X710 Adapter’ drv=igb_uio unused=
>
> Problem: rte eth rx burst(...) is not initializing the rte mbuf struct. Specifically, mb → packet type is always 0. However, rte pkt mtod(mb, struct ether hdr *) does return a pointer at the beginning of the Ethernet header and parsing other higher level headers (e.g., TCP) works correctly.
> Reproducing: Compile dpdk-16.04. Set verbose level=1 in testpmd.c and compile. Run ‘./testpmd – -i‘, ‘set fwd rxonly‘, ‘start‘.
>
> Example output:
> src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - nb_segs=1
> Unknown packet type // Should have been RTE_PTYPE_L2_ETHER:
> - Receive queue=0x0
>
> src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - nb_segs=1
> Unknown packet type // Should have been RTE_PTYPE_L2_ETHER:
> - Receive queue=0x0
> ...
> Repeating the steps above with dpdk-2.2.0 on the same machine does not have this issue. Example output on dpdk-2.2.0:
> src=00:00:00:00:00:01 - dst=00:00:00:00:00:02 - type=0x0800 - length=60 - nb_segs=1
>    - (outer) L2 type: ETHER - (outer) L3 type: IPV4_EXT_UNKNOWN - (outer) L4 type: UDP
>    - Tunnel type: Unknown - Inner L2 type: Unknown - Inner L3 type: Unknown - Inner L4
>     type: Unknown
> - Receive queue=0x0
> ...
>
>
> --
> Christopher Craig
> Cyber Security Software Engineer
> Cyber and Information Security Research Group, Oak Ridge National Laboratory
> http://www.csiir.ornl.gov || (865) 421 – 2992 (work)