From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F384E4C57 for ; Thu, 22 Jun 2017 10:17:01 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 22 Jun 2017 01:17:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,372,1493708400"; d="scan'208";a="870573648" Received: from unknown (HELO localhost.localdomain) ([10.239.128.239]) by FMSMGA003.fm.intel.com with ESMTP; 22 Jun 2017 01:16:58 -0700 Date: Thu, 22 Jun 2017 16:18:08 +0800 From: Jiayu Hu To: "Tan, Jianfeng" Cc: dev@dpdk.org, konstantin.ananyev@intel.com, yliu@fridaylinux.org, keith.wiles@intel.com, tiwei.bie@intel.com, lei.a.yao@intel.com Message-ID: <20170622081808.GA42993@localhost.localdomain> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20fd3a2c-9b61-2732-5a34-5acb8fc639a0@intel.com> User-Agent: Mutt/1.7.1 (2016-10-04) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 08:17:02 -0000 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 incoming > > packet of this flow. > > Each element in the item array records one packet information. It mainly > > includes two parts: > > - pkt: packet address > > - next_pkt_index: index of the next packet of the same flow in the item > > array. All packets of the same flow are chained by next_pkt_index. > > 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 following > > 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 reassemble > IP-fragmented packets, and then call this gro library to merge TCP packets. > And this procedure should be shown in an example for other users to refer. 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.