From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) by dpdk.org (Postfix) with ESMTP id 97C4B29CA for ; Wed, 6 Dec 2017 19:38:15 +0100 (CET) Received: by mail-wr0-f176.google.com with SMTP id h1so4914058wre.12 for ; Wed, 06 Dec 2017 10:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hKy3m2/j7/Y5gy6AdIMTt1HdK1mh7vw1sglqZcmqKwg=; b=foIeYnu7zTKz1SFSuGF8Eg1haPDlC4yivVy9n60K4qDmR6j3wgsc1eG8v0hcKVPvw3 z2QY2qkURVbOV+YQxyEN/aQZ7rZEh8MY9at6LQLChuY6Qlk+4ZxIPHOdlAKXZKcMbtGX 9MJqjGgxBs+755IvF35u4Qoo96dZ/kDmfCYiRGJyClGVUgTHUWki1yzjS+FvHI5WsgP5 GS6/63fs/d5+XENWBoKfd/Hihv9H9BN03sdCU1ohPZvTiqTqzsBDNxh1nHvmOGRTIJVy +r0ZCO+D3x62qmIQydsUIrS6gDpxrdQh7MHCTQeXfAR4NrhWmM9k5lsIqMT4aS/WqXcf VPDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hKy3m2/j7/Y5gy6AdIMTt1HdK1mh7vw1sglqZcmqKwg=; b=e38ixDsrzdKHQWUSafDDLeLvATnCt+gz7cMigifCYHm7wmEkKGbBFVL/auLEpbytiy m9p1/Pl6aw/F5/BMyyln59U2/reirK4UKysBuhdvCptATIaZJt019epjwArX3iwERvBD OnEVlUf2RzDU87AQhCnUyA/58pDjy7VkSKqZ9y/0UcOC7gz3AIXJZFqmRjcnF6z+Xtxo v7z6fA2fKQboCzihC26YBQT7Qn/Sdp/CGzkxVoi1o12aVvMqhTor+1uYZWzDy3CfbUrb 9BlQwzDQpmxND4wD2cCcf/e5P0dCmVHZ2jR6WILkjYIuR9XE3Mob99x0od0vMzCiRoCY am2Q== X-Gm-Message-State: AJaThX5PxPOWDlCetb2BTGoE/fzCVZNLPb2MOT6Fr0xslAX6y/Gq/+83 EYnVPLtSsMGqGvZc8+dpcUI= X-Google-Smtp-Source: AGs4zMZj09GVVDsbGZFxQAZAmZk1AG/Kk9yGZq8DC08lPONY68pCz3whvKkucGOP1Ak9nGbkJrb8hQ== X-Received: by 10.223.150.118 with SMTP id c51mr19366125wra.202.1512585495224; Wed, 06 Dec 2017 10:38:15 -0800 (PST) Received: from [192.168.1.115] ([94.205.75.192]) by smtp.gmail.com with ESMTPSA id u5sm3409241wmf.47.2017.12.06.10.38.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 10:38:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Ilya Matveychikov In-Reply-To: <20171206101200.031afa39@shemminger-XPS-13-9360> Date: Wed, 6 Dec 2017 22:38:12 +0400 Cc: dev@dpdk.org, jiayu.hu@intel.com Content-Transfer-Encoding: quoted-printable Message-Id: <2111ED2C-DB90-4AE3-893E-2406EFE129AD@gmail.com> References: <4F9781B2-338C-4154-BDA1-BC24D1B2B689@gmail.com> <20171206101200.031afa39@shemminger-XPS-13-9360> To: Stephen Hemminger X-Mailer: Apple Mail (2.3445.4.7) Subject: Re: [dpdk-dev] A question about GRO neighbor packet matching 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: Wed, 06 Dec 2017 18:38:15 -0000 > On Dec 6, 2017, at 10:12 PM, Stephen Hemminger = wrote: >=20 > On Wed, 6 Dec 2017 18:02:21 +0400 > Ilya Matveychikov wrote: >=20 >> Hello all, >>=20 >>=20 >> 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 =3D iph-prev.id + 1)? >=20 >=20 > No. >=20 >> ~~~ >> lib/librte_gro/gro_tcp4.c:check_seq_option() >> ... >> /* check if the two packets are neighbors */ >> tcp_dl0 =3D pkt0->pkt_len - pkt0->l2_len - pkt0->l3_len - = tcp_hl0; >> if ((sent_seq =3D=3D (item->sent_seq + tcp_dl0)) && >> (ip_id =3D=3D (item->ip_id + 1))) >> /* append the new packet */ >> return 1; >> else if (((sent_seq + tcp_dl) =3D=3D item->sent_seq) && >> ((ip_id + item->nb_merged) =3D=3D item->ip_id)) >> /* pre-pend the new packet */ >> return -1; >> else >> return 0; >> ~~~ >>=20 >> As per RFC791: >>=20 >> Identification: 16 bits >>=20 >> An identifying value assigned by the sender to aid in assembling = the >> fragments of a datagram. >=20 > 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. So, is my question correct and the code is wrong?