From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [PATCH v12 2/3] lib/gro: add TCP/IPv4 GRO support Date: Sun, 9 Jul 2017 00:37:46 +0800 Message-ID: <1d1750da-5118-9949-888b-3887d9c5de46@intel.com> References: <1499227716-116583-1-git-send-email-jiayu.hu@intel.com> <1499423958-84024-1-git-send-email-jiayu.hu@intel.com> <1499423958-84024-3-git-send-email-jiayu.hu@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: konstantin.ananyev@intel.com, yliu@fridaylinux.org, stephen@networkplumber.org, jingjing.wu@intel.com, lei.a.yao@intel.com To: Jiayu Hu , dev@dpdk.org Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 20233330D for ; Sat, 8 Jul 2017 18:37:48 +0200 (CEST) In-Reply-To: <1499423958-84024-3-git-send-email-jiayu.hu@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 7/7/2017 6:39 PM, Jiayu Hu wrote: > In this patch, we introduce five APIs to support TCP/IPv4 GRO. > - gro_tcp4_reassemble: reassemble an inputted TCP/IPv4 packet. > - gro_tcp4_tbl_create: create a TCP/IPv4 reassembly table, which is used > to merge packets. > - gro_tcp4_tbl_destroy: free memory space of a TCP/IPv4 reassembly table. > - gro_tcp4_tbl_pkt_count: return the number of packets in a TCP/IPv4 > reassembly table. > - gro_tcp4_tbl_timeout_flush: flush timeout packets from a TCP/IPv4 > reassembly table. > > TCP/IPv4 GRO API assumes all inputted packets are with correct IPv4 > and TCP checksums. And TCP/IPv4 GRO API doesn't update IPv4 and TCP > checksums for merged packets. If inputted packets are IP fragmented, > TCP/IPv4 GRO API assumes they are complete packets (i.e. with L4 > headers). > > In TCP/IPv4 GRO, we use a table structure, called TCP/IPv4 reassembly > table, to reassemble packets. A TCP/IPv4 reassembly table includes a key > array and a item array, where the key array keeps the criteria to merge > packets and the item array keeps packet information. > > One key in the key array points to an item group, which consists of > packets which have the same criteria value. If two packets are able to > merge, they must be in the same item group. Each key in the key array > includes two parts: > - criteria: the criteria of merging packets. If two packets can be > merged, they must have the same criteria value. > - start_index: the index of the first incoming packet of the item group. > > Each element in the item array keeps the information of one packet. It > mainly includes three parts: > - firstseg: the address of the first segment of the packet > - lastseg: the address of the last segment of the packet > - next_pkt_index: the index of the next packet in the same item group. > All packets in the same item group are chained by next_pkt_index. > With next_pkt_index, we can locate all packets in the same item > group one by one. > > To process an incoming packet needs three steps: > a. check if the packet should be processed. Packets with one of the > following properties won't be processed: > - FIN, SYN, RST, URG, PSH, ECE or CWR bit is set; > - packet payload length is 0. > b. traverse the key array to find a key which has the same criteria > value with the incoming packet. If find, goto step c. Otherwise, > insert a new key and insert the packet into the item array. > c. locate the first packet in the item group via the start_index in the > key. Then traverse all packets in the item group via next_pkt_index. > If find one packet which can merge with the incoming one, merge them > together. If can't find, insert the packet into this item group. > > Signed-off-by: Jiayu Hu Reviewed-by: Jianfeng Tan