From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id D21961396; Mon, 13 Mar 2017 23:13:21 +0100 (CET) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2017 15:13:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,161,1486454400"; d="scan'208";a="76203496" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga006.fm.intel.com with ESMTP; 13 Mar 2017 15:13:20 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.44]) by IRSMSX107.ger.corp.intel.com ([169.254.10.3]) with mapi id 14.03.0248.002; Mon, 13 Mar 2017 22:13:19 +0000 From: "Ananyev, Konstantin" To: "Dai, Wei" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH] examples/ip_fragmentation: fix check of packet type Thread-Index: AQHSmU8yg5E/bdsm10Cc+RyE+vgWlqGN/nwQgAQi4wCAADsAUIAAD44AgADu3uA= Date: Mon, 13 Mar 2017 22:13:18 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FACE96D@IRSMSX109.ger.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> In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D63A377662@PGSMSX106.gar.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 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 22:13:22 -0000 > > 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 m= ore > > 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 unifo= rm way. > > Again in that case for NICs that do support PTYPE offloads the performa= nce > > should be unaffected. > > Konstantin > > >=20 > 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. As an example for lpm: http://dpdk.org/browse/dpdk/tree/examples/l3fwd/l3fwd_lpm.c#n279 Konstantin > In this l3fwd rx callback function, it has done the same thing as my cod= e. > Anyway, I'd like to provide a v2 patch to deal with this issue in a unifo= rm way. >=20 > Thanks & Best Regards > -Wei