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 B1EB92C1A; Tue, 14 Mar 2017 02:18:38 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 18:18:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,161,1486454400"; d="scan'208";a="75733390" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by fmsmga005.fm.intel.com with ESMTP; 13 Mar 2017 18:18:36 -0700 Received: from pgsmsx101.gar.corp.intel.com ([169.254.1.119]) by KMSMSX152.gar.corp.intel.com ([169.254.11.139]) with mapi id 14.03.0248.002; Tue, 14 Mar 2017 09:18:34 +0800 From: "Dai, Wei" To: "Ananyev, Konstantin" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH] examples/ip_fragmentation: fix check of packet type Thread-Index: AQHSmU8y3XRgComwEk6xIyULTHsgDqGNeNmAgASn8RD//7XagIAAkkvAgABsXwCAALIcoA== Date: Tue, 14 Mar 2017 01:18:34 +0000 Message-ID: <49759EB36A64CF4892C1AFEC9231E8D64E508753@PGSMSX101.gar.corp.intel.com> References: <1489116490-2490-1-git-send-email-wei.dai@intel.com> <2601191342CEEE43887BDE71AB9772583FACD1BD@IRSMSX109.ger.corp.intel.com> <49759EB36A64CF4892C1AFEC9231E8D63A377512@PGSMSX106.gar.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FACE36C@IRSMSX109.ger.corp.intel.com> <49759EB36A64CF4892C1AFEC9231E8D63A377662@PGSMSX106.gar.corp.intel.com> <2601191342CEEE43887BDE71AB9772583FACE96D@IRSMSX109.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772583FACE96D@IRSMSX109.ger.corp.intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODJmYmYxNDMtMGY4Ni00YTZkLWI2ZDAtYWI1MmFiMjNhY2E3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlVtVWVKUlliMnp2YVJPWmVmSXNwRWZyY0NjUHZnUGI3U0VneU53UmFzMTg9In0= x-ctpclassification: CTP_IC x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] examples/ip_fragmentation: fix check of packet type X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 01:18:39 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Tuesday, March 14, 2017 6:13 AM > To: Dai, Wei ; dev@dpdk.org > Cc: stable@dpdk.org > Subject: RE: [PATCH] examples/ip_fragmentation: fix check of packet type >=20 >=20 >=20 > > > Hi Wei, > > > > > > > > > > > Hi, Konstantin > > > > I see your point. > > > > I think your method can work. > > > > But I think your method is a bit complex. As you method need to > > > > add more > > > codes. > > > > Anyway this is a simple bug. > > > > How do you think now ? > > > > > > I still think it is better for all apps to handle this issue in a uni= form way. > > > Again in that case for NICs that do support PTYPE offloads the > > > performance should be unaffected. > > > Konstantin > > > > > > > I have just had a quick look through the l3fwd and didn't find any > > codes to check what ptypes capabilities ae provided by stuff below DPDK > PMD & its base driver. > > L3fwd only check an input argument "--parse-ptype" to enable ptype > > check implemented in a Rx callback function. >=20 > As an example for lpm: > http://dpdk.org/browse/dpdk/tree/examples/l3fwd/l3fwd_lpm.c#n279 > Konstantin Thanks for your guide. I will use rte_eth_dev_get_supported_ptypes( ) in my v2 patch. >=20 >=20 > > In this l3fwd rx callback function, it has done the same thing as my c= ode. > > Anyway, I'd like to provide a v2 patch to deal with this issue in a uni= form way. > > > > Thanks & Best Regards > > -Wei