From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [PATCH v5 2/3] lib/gro: add TCP/IPv4 GRO support Date: Thu, 22 Jun 2017 09:35:23 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "Ananyev, Konstantin" , "yliu@fridaylinux.org" , "Wiles, Keith" , "Bie, Tiwei" , "Yao, Lei A" To: "Hu, Jiayu" Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1DDBF5699 for ; Thu, 22 Jun 2017 11:35:26 +0200 (CEST) In-Reply-To: <20170622081808.GA42993@localhost.localdomain> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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).