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 814E77E18 for ; Wed, 19 Nov 2014 01:19:36 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 18 Nov 2014 16:29:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,413,1413270000"; d="scan'208";a="634185926" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by fmsmga002.fm.intel.com with ESMTP; 18 Nov 2014 16:29:31 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 19 Nov 2014 08:29:30 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.182]) by shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id 14.03.0195.001; Wed, 19 Nov 2014 08:29:29 +0800 From: "Zhang, Helin" To: "Ananyev, Konstantin" , "Liu, Jijiang" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e Thread-Index: AQHQAwKd7WlnmZlXKE+2MWT/5bnNP5xlussAgACxIoD//4/egIABHY1w Date: Wed, 19 Nov 2014 00:29:29 +0000 Message-ID: References: <1416296251-7534-1-git-send-email-jijiang.liu@intel.com> <2601191342CEEE43887BDE71AB977258213B581A@IRSMSX105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB977258213B58B9@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213B58B9@IRSMSX105.ger.corp.intel.com> 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 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 00:19:38 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Tuesday, November 18, 2014 11:26 PM > To: Zhang, Helin; Liu, Jijiang; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e >=20 >=20 >=20 > > -----Original Message----- > > From: Zhang, Helin > > Sent: Tuesday, November 18, 2014 2:12 PM > > To: Ananyev, Konstantin; Liu, Jijiang; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, > > > Konstantin > > > Sent: Tuesday, November 18, 2014 7:33 PM > > > To: Liu, Jijiang; dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > 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 > > > > applications 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 in > > > > 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. > > We met quite a lot of similar situations, we designed a new way for > > i40e, then have to rework igb/ixgbe. E.g. configuring reta, flow direct= or, etc. > > If possible, send the patch set as smaller as possible might be > > better. I guess igb/ixgbe will be done soon later. > > > > > As right now, only i40e implementation can distinguish packet_type > > > properly, I think all other PMDs for the freshly received packet shou= ld do: > > > mbuf->packet_type =3D RTE_PTYPE_UNDEF; > > If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf > initialized to 0? >=20 > Yes RTE_PTYPE_UNDEF =3D=3D 0 >=20 > > If yes, nothing needs to be done in igb/ixgbe for now. >=20 > Could you explain to me why is that? > As I remember none of our RX functions reset the whole mbuf to all zeroes= . > None of them even call rte_pktmbuf_reset() for performance reasons. > So what/who would prevent reset packet_type of the freshly received > packet_type to zero? So mbuf header fields are not zero-ed by default? That might not be what I = guessed. > BTW, I think that rte_pktmbuf_reset() need to reset packet_type too. >=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? > > > > > > Konstantin > > > > > > > -- > > > > 1.7.7.6 > > > > Regards, > > Helin