DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: "Craig, Chris A." <craigca@ornl.gov>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "Taylor, Curtis R." <taylorcr@ornl.gov>
Subject: Re: [dpdk-dev] Possible Bug: DPDK 16.04 Empty packet_type
Date: Wed, 6 Jul 2016 09:39:24 +0800	[thread overview]
Message-ID: <990e4454-d7fb-67ae-d931-1718d9a135bf@intel.com> (raw)
In-Reply-To: <AE3C5987-768C-4D09-924A-3D000ED38414@ornl.gov>


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@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)

      reply	other threads:[~2016-07-06  1:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05 19:54 Craig, Chris A.
2016-07-06  1:39 ` Tan, Jianfeng [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=990e4454-d7fb-67ae-d931-1718d9a135bf@intel.com \
    --to=jianfeng.tan@intel.com \
    --cc=craigca@ornl.gov \
    --cc=dev@dpdk.org \
    --cc=taylorcr@ornl.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).