From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 9D77DFFA for ; Thu, 16 Jul 2015 01:51:33 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 15 Jul 2015 16:51:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,484,1432623600"; d="scan'208";a="729695010" Received: from kmsmsx154.gar.corp.intel.com ([172.21.73.14]) by orsmga001.jf.intel.com with ESMTP; 15 Jul 2015 16:51:31 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 16 Jul 2015 07:51:29 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.129]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.46]) with mapi id 14.03.0224.002; Thu, 16 Jul 2015 07:51:26 +0800 From: "Zhang, Helin" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v10 00/19] unified packet type Thread-Index: AQHQv1JMqPYOVAoco0O906mZSB8OfZ3dM4BA Date: Wed, 15 Jul 2015 23:51:26 +0000 Message-ID: References: <1435912347-19499-1-git-send-email-helin.zhang@intel.com> <1436459501-14173-1-git-send-email-helin.zhang@intel.com> <1656470.VpSR9lnEEE@xps13> In-Reply-To: <1656470.VpSR9lnEEE@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v10 00/19] unified 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, 15 Jul 2015 23:51:34 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, July 15, 2015 4:01 PM > To: Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v10 00/19] unified packet type >=20 > 2015-07-10 00:31, Helin Zhang: > > Currently only 6 bits which are stored in ol_flags are used to > > indicate the packet types. This is not enough, as some NIC hardware > > can recognize quite a lot of packet types, e.g i40e hardware can > > recognize more than 150 packet types. Hiding those packet types hides > > hardware offload capabilities which could be quite useful for improving > performance and for end users. > > So an unified packet types are needed to support all possible PMDs. A > > 16 bits packet_type in mbuf structure can be changed to 32 bits and > > used for this purpose. In addition, all packet types stored in ol_flag > > field should be deleted at all, and 6 bits of ol_flags can be save as t= he benifit. > > > > Initially, 32 bits of packet_type can be divided into several sub > > fields to indicate different packet type information of a packet. The > > initial design is to divide those bits into fields for L2 types, L3 > > types, L4 types, tunnel types, inner L2 types, inner L3 types and > > inner L4 types. All PMDs should translate the offloaded packet types > > into these 7 fields of information, for user applications. > > > > To avoid breaking ABI compatibility, currently all the code changes > > for unified packet type are disabled at compile time by default. Users > > can enable it manually by defining the macro of RTE_NEXT_ABI. The code > > changes will be valid by default in a future release, and the old > > version will be deleted accordingly, after the ABI change process is do= ne. >=20 > Applied with fixes for cxgbe and mlx4, thanks everyone >=20 > The macro RTE_ETH_IS_TUNNEL_PKT may need to take RTE_PTYPE_INNER_* > into account. Thank you so much! Thanks to all the contributors! Helin