From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jianfeng.tan@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1DDBF5699 for <dev@dpdk.org>; Thu, 22 Jun 2017 11:35:26 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2017 02:35:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,372,1493708400"; d="scan'208";a="277291498" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga004.fm.intel.com with ESMTP; 22 Jun 2017 02:35:26 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Jun 2017 02:35:26 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Jun 2017 02:35:26 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.116]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.197]) with mapi id 14.03.0319.002; Thu, 22 Jun 2017 17:35:23 +0800 From: "Tan, Jianfeng" <jianfeng.tan@intel.com> To: "Hu, Jiayu" <jiayu.hu@intel.com> CC: "dev@dpdk.org" <dev@dpdk.org>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "yliu@fridaylinux.org" <yliu@fridaylinux.org>, "Wiles, Keith" <keith.wiles@intel.com>, "Bie, Tiwei" <tiwei.bie@intel.com>, "Yao, Lei A" <lei.a.yao@intel.com> Thread-Topic: [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO support Thread-Index: AQHS6ANUFtpEDlXsqU2S/gDaZeW6bqIsVYYAgAO0fwCAAJncwA== Date: Thu, 22 Jun 2017 09:35:23 +0000 Message-ID: <ED26CBA2FAD1BF48A8719AEF02201E36512137F8@SHSMSX103.ccr.corp.intel.com> References: <1496833731-53653-1-git-send-email-jiayu.hu@intel.com> <1497770469-16661-1-git-send-email-jiayu.hu@intel.com> <1497770469-16661-3-git-send-email-jiayu.hu@intel.com> <20fd3a2c-9b61-2732-5a34-5acb8fc639a0@intel.com> <20170622081808.GA42993@localhost.localdomain> In-Reply-To: <20170622081808.GA42993@localhost.localdomain> 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 v5 2/3] lib/gro: add TCP/IPv4 GRO support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 22 Jun 2017 09:35:27 -0000 Hi Jiayu, > -----Original Message----- > From: Hu, Jiayu > Sent: Thursday, June 22, 2017 4:18 PM > To: Tan, Jianfeng > Cc: dev@dpdk.org; Ananyev, Konstantin; yliu@fridaylinux.org; Wiles, Keith= ; > Bie, Tiwei; Yao, Lei A > Subject: Re: [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO support >=20 > On Mon, Jun 19, 2017 at 11:43:20PM +0800, Tan, Jianfeng wrote: > > > > > > On 6/18/2017 3:21 PM, Jiayu Hu wrote: > > > > > > Each element in the flow array records the information of one flow, > > > which includes two parts: > > > - key: the criteria of the same flow. If packets have the same key > > > value, they belong to the same flow. > > > - start_index: the index of the first incoming packet of this flow in > > > the item array. With start_index, we can locate the first incomi= ng > > > packet of this flow. > > > Each element in the item array records one packet information. It mai= nly > > > includes two parts: > > > - pkt: packet address > > > - next_pkt_index: index of the next packet of the same flow in the it= em > > > array. All packets of the same flow are chained by next_pkt_inde= x. > > > With next_pkt_index, we can locate all packets of the same flow > > > one by one. > > > > > > To process an incoming packet, we need three steps: > > > a. check if the packet should be processed. Packets with the followin= g > > > properties won't be processed: > > > - packets without data; > > > - packets with wrong checksums; > > > > Why do we care to check this kind of error? Can we just suppose the > > applications have already dropped the packets with wrong cksum? > > > > > - fragmented packets. > > > > IP fragmented? I don't think we need to check it here either. It's the > > application's responsibility to call librte_ip_frag firstly to reassemb= le > > IP-fragmented packets, and then call this gro library to merge TCP pack= ets. > > And this procedure should be shown in an example for other users to ref= er. >=20 > If we leave this check to applications, they have to call librte_ip_frag > first, then call GRO library. If they call GRO library first, error > happens. But if GRO checks if the packet is fragmented, no error happens. > IMO, it's more flexible. Besides, for GRO library, to check if the packet > is fragmented is very simple. Just to check if DF bit is set is enough. > So I still think GRO library need to check it. I would expect ip fragment is also a gro engine (might be two for ipv4 and = ipv6).