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 AEB0858E8 for ; Tue, 10 Feb 2015 01:53:57 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 09 Feb 2015 16:53:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,547,1418112000"; d="scan'208";a="683389153" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by orsmga002.jf.intel.com with ESMTP; 09 Feb 2015 16:53:55 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 10 Feb 2015 08:53:54 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.161]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.46]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 08:53:53 +0800 From: "Zhang, Helin" To: "Richardson, Bruce" Thread-Topic: [PATCH v2 01/15] mbuf: add definitions of unified packet types Thread-Index: AQHQRFMFkOc0mveKtkGmxZiFN3/LHJzpDnHA Date: Tue, 10 Feb 2015 00:53:52 +0000 Message-ID: References: <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <1423464049-13457-1-git-send-email-helin.zhang@intel.com> <1423464049-13457-2-git-send-email-helin.zhang@intel.com> <20150209102724.GA10516@bricha3-MOBL3> In-Reply-To: <20150209102724.GA10516@bricha3-MOBL3> 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 v2 01/15] mbuf: add definitions of unified packet types 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: Tue, 10 Feb 2015 00:53:58 -0000 Hi Bruce Fortunately I have Steve as the author of a sub-patch for vector PMD in thi= s patch set. That means we have already taken into account the VPMD in it. All is workable with vPMD, and with performance result mentioned. Everything is done for this mbuf changes. Regards, Helin > -----Original Message----- > From: Richardson, Bruce > Sent: Monday, February 9, 2015 6:27 PM > To: Zhang, Helin > Cc: dev@dpdk.org; Cao, Waterman; Liang, Cunming; Liu, Jijiang; Ananyev, > Konstantin > Subject: Re: [PATCH v2 01/15] mbuf: add definitions of unified packet typ= es >=20 > On Mon, Feb 09, 2015 at 02:40:35PM +0800, Helin Zhang wrote: > > As there are only 6 bit flags in ol_flags for indicating packet types, > > which is not enough to describe all the possible packet types hardware > > can recognize. For example, i40e hardware can recognize more than 150 > > packet types. Unified packet type is composed of tunnel type, L3 type, > > L4 type and inner L3 type fields, and can be stored in mbuf field of > > 'packet_type' which is modified from 16 bits to 32 bits in mbuf structu= re. > > Accordingly, the structure of 'rte_kni_mbuf' needs to be modifed as wel= l. > > > > Signed-off-by: Helin Zhang > > Signed-off-by: Cunming Liang > > Signed-off-by: Jijiang Liu > > --- > > .../linuxapp/eal/include/exec-env/rte_kni_common.h | 4 +- > > lib/librte_mbuf/rte_mbuf.h | 113 > +++++++++++++++++++-- > > 2 files changed, 108 insertions(+), 9 deletions(-) > > > > v2 changes: > > * Enlarged the packet_type field from 16 bits to 32 bits. > > * Redefined the packet type sub-fields. > > * Updated the 'struct rte_kni_mbuf' for KNI according to the mbuf chang= es. > > >=20 > Since these changes to the mbuf will break the operation of the vector dr= iver, > that vector driver needs to be taken into account here. >=20 > Some suggestions/options: > 1. Temporarily disable the VPMD at compile time or at run time as part of= this > patch, and put the vector changes as the next patch (re-enabling the driv= er too) > 2. Put in the minimum changes for the new mbuf layout into this patch. It= will > make this patch a little longer, but may still be doable as it's only a c= ouple of > fields changing, not the whole structure. >=20 > /Bruce