From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 610FFD148; Mon, 13 Mar 2017 08:56:13 +0100 (CET) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 00:56:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,157,1486454400"; d="scan'208";a="74700137" Received: from kmsmsx154.gar.corp.intel.com ([172.21.73.14]) by orsmga005.jf.intel.com with ESMTP; 13 Mar 2017 00:56:10 -0700 Received: from pgsmsx106.gar.corp.intel.com ([169.254.9.9]) by KMSMSX154.gar.corp.intel.com ([169.254.12.113]) with mapi id 14.03.0248.002; Mon, 13 Mar 2017 15:56:09 +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//7XagIAAkkvA Date: Mon, 13 Mar 2017 07:56:08 +0000 Message-ID: <49759EB36A64CF4892C1AFEC9231E8D63A377662@PGSMSX106.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> In-Reply-To: <2601191342CEEE43887BDE71AB9772583FACE36C@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTYwMTI0ZjItNGEzNS00YjVhLThiZDYtOTE0YWU3YTE2ZDM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjJsUUhoYnVXK3ltMHNtUk5lQTk3ejFqcDhqMzFoR21yQ0tRQmdPY25LcU09In0= x-ctpclassification: CTP_IC x-originating-ip: [172.30.20.206] 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: Mon, 13 Mar 2017 07:56:14 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Monday, March 13, 2017 3:02 PM > To: Dai, Wei ; dev@dpdk.org > Cc: stable@dpdk.org > Subject: RE: [PATCH] examples/ip_fragmentation: fix check of packet type >=20 > Hi Wei, >=20 > > > > 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 mor= e > codes. > > Anyway this is a simple bug. > > How do you think now ? >=20 > I still think it is better for all apps to handle this issue in a uniform= way. > Again in that case for NICs that do support PTYPE offloads the performanc= e > should be unaffected. > Konstantin >=20 I have just had a quick look through the l3fwd and didn't find any codes to= =20 check what ptypes capabilities ae provided by stuff below DPDK PMD & its ba= se driver. L3fwd only check an input argument "--parse-ptype" to enable ptype check im= plemented in a Rx callback function. In this l3fwd rx callback function, it has done the same thing as my code. Anyway, I'd like to provide a v2 patch to deal with this issue in a uniform= way. Thanks & Best Regards -Wei