From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: A question about GRO neighbor packet matching
Date: Wed, 6 Dec 2017 10:12:00 -0800
Message-ID: <20171206101200.031afa39@shemminger-XPS-13-9360>
References: <4F9781B2-338C-4154-BDA1-BC24D1B2B689@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, jiayu.hu@intel.com
To: Ilya Matveychikov <matvejchikov@gmail.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com
 [209.85.192.174]) by dpdk.org (Postfix) with ESMTP id CDBCC1C00
 for <dev@dpdk.org>; Wed,  6 Dec 2017 19:12:05 +0100 (CET)
Received: by mail-pf0-f174.google.com with SMTP id c204so2599008pfc.13
 for <dev@dpdk.org>; Wed, 06 Dec 2017 10:12:05 -0800 (PST)
In-Reply-To: <4F9781B2-338C-4154-BDA1-BC24D1B2B689@gmail.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, 6 Dec 2017 18:02:21 +0400
Ilya Matveychikov <matvejchikov@gmail.com> wrote:

> Hello all,
> 
> 
> My question is about neighbor packet matching algorithm for TCP. Is it
> correct to expect that IP packets should have continuous ID enumeration
> (i.e. iph-next.id = iph-prev.id + 1)?


No.

> ~~~
> lib/librte_gro/gro_tcp4.c:check_seq_option()
> 	...
> 	/* check if the two packets are neighbors */
> 	tcp_dl0 = pkt0->pkt_len - pkt0->l2_len - pkt0->l3_len - tcp_hl0;
> 	if ((sent_seq == (item->sent_seq + tcp_dl0)) &&
> 			(ip_id == (item->ip_id + 1)))
> 		/* append the new packet */
> 		return 1;
> 	else if (((sent_seq + tcp_dl) == item->sent_seq) &&
> 			((ip_id + item->nb_merged) == item->ip_id))
> 		/* pre-pend the new packet */
> 		return -1;
> 	else
> 		return 0;
> ~~~
> 
> As per RFC791:
> 
>   Identification:  16 bits
> 
>     An identifying value assigned by the sender to aid in assembling the
>     fragments of a datagram.

The IP header id is meaningless in most TCP sessions.
Good TCP implementations use PMTU discovery which sets the Don't Fragment bit.
With DF, the IP id is unused (since no fragmentation).
Many implementations just send 0 since generating unique IP id requires an
atomic operation which is potential bottleneck.