From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9942542990; Thu, 20 Apr 2023 04:46:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 824434114B; Thu, 20 Apr 2023 04:46:04 +0200 (CEST) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by mails.dpdk.org (Postfix) with ESMTP id 6EA8540A79 for ; Thu, 20 Apr 2023 04:46:02 +0200 (CEST) Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1a92513abebso7154105ad.2 for ; Wed, 19 Apr 2023 19:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1681958761; x=1684550761; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=8vheC69MhXLABs2k+89BH1pD3ZIDk1SAYMnEeEfD7D0=; b=4Uia6F0/ewl5bRHvD8vutP+S+h7I7HPuuPcn/Ne960QXBPnY8tn/tMUfKDy5VtSm2T PGoYi1RAR0eoC6j3PPuX4OWEOilZnoB2P3gacdT228EtHmgRPqpaG+ixy8cxT0o9adzy dRuEKNksrNpIMrCZ1PG+eqn2i0EPK5LsxsSKBXug2hHILIN48XC1dpx9BNzv4kB9Y+1Q d+aB99ofm/eATlBhy63T43bwOrOdfiDu/FMghBZg3SSxxF80aFbuQdp28RQAZV7mIlal ufFvBj7zfKoFJrNZ+cnRQysZALdnOaK+jBJqFd2dqv+pFO5EL+LRJzjSzZiecXuD+ESU si7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681958761; x=1684550761; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8vheC69MhXLABs2k+89BH1pD3ZIDk1SAYMnEeEfD7D0=; b=ADBSHHw9FVGl/MF3vZk1p6c/dS+hHIIgjUacyl7mGSVX6nB7F9QgQCVjo3d86oJeql z/bEJO9+AQFJIv96bkR9hgPbeAM/+xY9YgClf8bBKO2zK6pDUOjRE9BcCX8J/SbGM6Rw QSt/gPXBZAF6wylWVw30MzCq+tU/gm2zdANdq/ngDCFLAIU1p7Rixm+wr7pd7B+xZnay 6mkXzy4CxXwppqFu7I8aHMckbPSmOZqY/qISUYpK9d6jCrhOpCy0sy3dqVB6mR8u4Ej6 0qlU6D/MYwLc2CQb2crPQ0nbqQ9WtB6fVxfT7j9QwpP9DQvUT8vohA69Pk7Ufyc9WNnC cElQ== X-Gm-Message-State: AAQBX9eeJ53IVEC/VuWANxbTultvZS775GRr0JmNBHCSD8anNE8A/EE9 7CNt7y5owLkVMGNfi/CgtKZbbA== X-Google-Smtp-Source: AKy350ZAFC7LnY9zAGBtSpoVc3riKy/fT9YbPSwqBPkNNFVHWzGQIh7c1jKYrLCnEI3vXXASxwisDQ== X-Received: by 2002:a17:903:41cf:b0:1a8:106c:4a1a with SMTP id u15-20020a17090341cf00b001a8106c4a1amr55354ple.1.1681958761450; Wed, 19 Apr 2023 19:46:01 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id a13-20020a1709027d8d00b001a647709860sm132971plm.157.2023.04.19.19.46.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 19:46:01 -0700 (PDT) Date: Wed, 19 Apr 2023 19:45:53 -0700 From: Stephen Hemminger To: "Hu, Jiayu" Cc: "jiangheng (G)" , "users@dpdk.org" , "dev@dpdk.org" Subject: Re: [GRO] check whether ip_id continuity needs to be checked when two TCP packets are merged. Message-ID: <20230419194553.0b3bb1ff@hermes.local> In-Reply-To: References: <3bec4e84b0dc406887e9df08ddfd91ad@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, 20 Apr 2023 02:30:41 +0000 "Hu, Jiayu" wrote: > Hi Cheng, > > > -----Original Message----- > > From: jiangheng (G) > > Sent: Saturday, April 15, 2023 10:46 PM > > To: users@dpdk.org; Hu, Jiayu ; dev@dpdk.org > > Subject: [GRO] check whether ip_id continuity needs to be checked when > > two TCP packets are merged. > > > > Hi jiayu.hu > > > > It cannot be guaranteed that 16bit identification field of ip packets in the > > same tcp stream will be continuous. > > Please help check whether ip_id continuity needs to be checked when two > > TCP packets are merged? > > Seems to modify the following code, gro will aggregate better, and work > > better: > > > > diff --git a/lib/gro/gro_tcp4.h b/lib/gro/gro_tcp4.h index > > 212f97a042..06faead7b5 100644 > > --- a/lib/gro/gro_tcp4.h > > +++ b/lib/gro/gro_tcp4.h > > @@ -291,12 +291,10 @@ check_seq_option(struct gro_tcp4_item *item, > > /* check if the two packets are neighbors */ > > len = pkt_orig->pkt_len - l2_offset - pkt_orig->l2_len - > > pkt_orig->l3_len - tcp_hl_orig; > > - if ((sent_seq == item->sent_seq + len) && (is_atomic || > > - (ip_id == item->ip_id + 1))) > > + if (sent_seq == item->sent_seq + len) > > For atomic packets, the IP ID field is ignored, as it can be set in various ways. > For non-atomic packets, it follows Linux kernel tcp_gro_receive(). > > Is this change specific to your case? Can you give more details on why it helps? Many OS's don't change IP ID if DF bit is set. See RFC 6864 for details >> The IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly.