From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id E98C99E7 for ; Wed, 6 Jul 2016 03:39:26 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP; 05 Jul 2016 18:39:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,316,1464678000"; d="scan'208,217";a="841210340" Received: from unknown (HELO [10.239.67.193]) ([10.239.67.193]) by orsmga003.jf.intel.com with ESMTP; 05 Jul 2016 18:39:24 -0700 To: "Craig, Chris A." , "dev@dpdk.org" References: Cc: "Taylor, Curtis R." From: "Tan, Jianfeng" Message-ID: <990e4454-d7fb-67ae-d931-1718d9a135bf@intel.com> Date: Wed, 6 Jul 2016 09:39:24 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] Possible Bug: DPDK 16.04 Empty packet_type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 01:39:27 -0000 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 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)