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 E059B682E for ; Wed, 19 Nov 2014 11:03:18 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 19 Nov 2014 01:47:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,415,1413270000"; d="scan'208";a="624768333" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga001.fm.intel.com with ESMTP; 19 Nov 2014 01:47:19 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by IRSMSX153.ger.corp.intel.com ([163.33.192.75]) with mapi id 14.03.0195.001; Wed, 19 Nov 2014 09:47:16 +0000 From: "Ananyev, Konstantin" To: "Liu, Jijiang" Thread-Topic: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e Thread-Index: AQHQAwKdtAq8eAMesEe9YHLlK90XlpxmOTcwgAAiQACAACaRwIAA0JCAgABfveA= Date: Wed, 19 Nov 2014 09:47:15 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213B6AD3@IRSMSX105.ger.corp.intel.com> References: <1416296251-7534-1-git-send-email-jijiang.liu@intel.com> <2601191342CEEE43887BDE71AB977258213B581A@IRSMSX105.ger.corp.intel.com> <20141118130828.GA10768@bricha3-MOBL3> <2601191342CEEE43887BDE71AB977258213B58D0@IRSMSX105.ger.corp.intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9C02C@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9C02C@SHSMSX101.ccr.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] 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 0/4] Translate packet types for i40e 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, 19 Nov 2014 10:03:20 -0000 > -----Original Message----- > From: Liu, Jijiang > Sent: Wednesday, November 19, 2014 3:53 AM > To: Ananyev, Konstantin > Cc: dev@dpdk.org; Richardson, Bruce > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e >=20 >=20 >=20 > > -----Original Message----- > > From: Ananyev, Konstantin > > Sent: Tuesday, November 18, 2014 11:29 PM > > To: Richardson, Bruce > > Cc: Liu, Jijiang; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > > > > -----Original Message----- > > > From: Richardson, Bruce > > > Sent: Tuesday, November 18, 2014 1:08 PM > > > To: Ananyev, Konstantin > > > Cc: Liu, Jijiang; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > On Tue, Nov 18, 2014 at 11:33:24AM +0000, Ananyev, Konstantin wrote: > > > > Hi Frank, > > > > > > > > > -----Original Message----- > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jijiang Liu > > > > > Sent: Tuesday, November 18, 2014 7:37 AM > > > > > To: dev@dpdk.org > > > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > > > > > The i40e NIC can recognize many packet types, including ordinary > > > > > L2 packet format and tunneling packet format such as IP in IP, IP > > > in > > > > > GRE, MAC in GRE and MAC in UDP. > > > > > > > > > > This patch set provides abstract definitions of packet types, > > > > > which can help user to use these packet types directly in their a= pplications > > to speed up receive packet analysis. > > > > > > > > > > Moreover, this patch set translates i40e packet types to abstract > > > > > packet types in i40e driver, and make the corresponding changes i= n test > > applications. > > > > > > > > > > Jijiang Liu (4): > > > > > Add packet type and IP header check in rte_mbuf > > > > > Remove the PKT_RX_TUNNEL_IPV4_HDR and the > > PKT_RX_TUNNEL_IPV6_HDR > > > > > Translate i40e packet types > > > > > Make the corresponding changes in test-pmd > > > > > > > > > > app/test-pmd/csumonly.c | 12 +- > > > > > app/test-pmd/rxonly.c | 15 +- > > > > > lib/librte_mbuf/rte_mbuf.h | 225 ++++++++++++++- > > > > > lib/librte_pmd_i40e/i40e_rxtx.c | 604 > > > > > +++++++++++++++++++++------------------ > > > > > 4 files changed, 569 insertions(+), 287 deletions(-) > > > > > > > > > > > > > The patch looks good to me in general. > > > > Though I think it is not complete: we need to make sure that all > > > > PMDs RX functions will set mbuf's packet_type to the defined value. > > > > As right now, only i40e implementation can distinguish packet_type > > > > properly, I think all other PMDs for the freshly received packet sh= ould do: > > > > mbuf->packet_type =3D RTE_PTYPE_UNDEF; >=20 > In current codes, the mbuf->packet_type =3D 0 has already been done in = rte_pktmbuf_reset(). Ok yes, I missed that: indeed we already do mbuf->packet_type =3D 0 in rte= _pktmbuf_reset(). Though, as I said in another mail our PMDs RX routines don't use rte_pktmbu= f_reset() for performance reasons. So, I still think that scalar ixgbe, igb/em and virtio/vmnext3 need to be u= pdated.=20 >=20 > > > > Another thing: right now mbuf's packet_type is uint16_t. > > > > While enum rte_eth_packet_type will be interpreted by the compiler = as 'int' > > (32bits). > > > > We can either change enum to a lot of defines (which I don't really > > > > like to do) or probably just add a comment somewhere that enum > > rte_eth_packet_type should never exceed UINT16_MAX value? > > > > > > > Add a RTE_PTYPE_MAX value =3D UINT16_MAX to the enum, perhaps? > > > > Yep, add something like RTE_PTYPE_MAX =3D UINT16_MAX and RTE_PTYPE_MIN > > =3D=3D 0 seems like a good thing to me too. >=20 > Ok, will add RTE_PTYPE_MAX =3D UINT16_MAX into rte_eth_packet_type. > Currently, RTE_PTYPE_UNDEF is 0, if the RTE_PTYPE_MIN needed, and RTE_PT= YPE_MIN =3D 1, but I think it is not necessary to add > RTE_PTYPE_MIN. Why you need to setup RTE_PTYPE_MIN =3D=3D 1? Why it can't be done like that: enum rte_eth_ptype {=20 RTE_PTYPE_MIN =3D 0, RTE_PTYPE_UDEF =3D RTE_PTYPE_MIN, .... RTE_PTYPE_MAX =3D UINT16_MAX }; ? >=20 > Moreover, there won't be an icc compilation error for the following code= s, so we can set mb-> packet_type using enum paket_type > directly in i40e driver. > enum rte_eth_packet_type paket_type; > mb-> packet_type =3D paket_type; //packet_type is uint16 in mbuf. >=20 > But there will be an icc compilation error for the following codes, we mu= st convert packet_type in mbuf . > enum rte_eth_packet_type paket_type; > paket_type =3D mb-> packet_type ; //packet_type is uint16 in mbuf. >=20 > and it needs to change as follows to avoid compilation error using icc. > paket_type =3D(rte_eth_packet_type) mb-> packet_type; Not sure I understand you here. I think you'll still need to do a direct conversion to keep old versions of= icc happy: mb-> packet_type =3D (uint16_t)paket_type; ... paket_type =3D(rte_eth_packet_type) mb-> packet_type; =20 >=20 > > > > > > > > /Bruce