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 442DD4586D; Mon, 26 Aug 2024 17:48:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1FABD4066F; Mon, 26 Aug 2024 17:48:25 +0200 (CEST) Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) by mails.dpdk.org (Postfix) with ESMTP id 4FA914003C for ; Mon, 26 Aug 2024 17:48:23 +0200 (CEST) Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-2701c010388so2697023fac.0 for ; Mon, 26 Aug 2024 08:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1724687302; x=1725292102; darn=dpdk.org; 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=mg1s2k33sy59dFz7H0MgFTf7+sDMqXjjqfY6KRam9zw=; b=fS84qJTq/tqJ0VmdtwztkdZmW7FQKt4nAg+tfKPmPAXPIs37cG0W+2arYlC2B5imvj stzFBsfSnEmBjFgf5F/qTW5AAmcJZFSfGcUz4wlw6D/3uH6QbbHQoQtl74hzniTFBToo N4c2YQzKo2LdjhRT9cWriroCsl55NivrqDq0EOCjNa8eqLZRG364Ro5lF4vEhZszsQqU vQ16hN10uXxMAoO4utxaOvN/lnhbRIwDRMnZ2HXst9ZLzuuZVeOl8BBrm89XHlm8xVFk BBpTfDBYOc/J7V3/1k7FUc2SzvZQH04Wz+Hl23BiWrekwJU9dqgaD1L8utow+ivlbA5Z 3doA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724687302; x=1725292102; 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=mg1s2k33sy59dFz7H0MgFTf7+sDMqXjjqfY6KRam9zw=; b=snSX+c7j6QCpvWgmU2uBwPnHfJQgnMmkZ5rP/R4Xq13pAnLF/mmv2SaAs5snKshZdk KwAY5WzgernjETGlUQIA5xxONB6tO8adEwjf8SnILV8UlCZhV67mYnEtlauxDnaxVCKy okRsuFsmk0Gww3lAPif2Ef3BcmAQNutq34lPBSujIz5d9AvM2HTzwCuA1Aj2HqDSBgtb OwKuXqHkPGMEJyPfZzWMhEgl7LJXPUOhl8+SWl3T6WYApiNWX2czrUskusqMB6kvGgRv cPFYRceR8fmoUgG7zQaGtvffndWZjAkatbxMcEFRYYNWWPhZqTfXrvp2/nPlt8kDS3Rf C/bg== X-Forwarded-Encrypted: i=1; AJvYcCUDzQxPYsIfyJZQS8f23nDoCx8A+KuHikCATD1SPDn8ezXOa3iV8TYmhHJsBXhqBrxQdXA=@dpdk.org X-Gm-Message-State: AOJu0Yx/JZjhexm95HRwDj9Rm1xmzYLRmTK8HiEk8/YavuNLthWO0y1d 5EizcqF2WM6QzaRgvRHULm7iOj6VuSK+L0CfOrha2y1fC/h6stsHooszjHDNUXA= X-Google-Smtp-Source: AGHT+IEbLz0qIQwVVqC6/Aow9Mlm9gyiVrhg1htQ8lC9N+cd6vHMt0AhwPZrjggXo+7HYk1AtelPEQ== X-Received: by 2002:a05:6870:f29a:b0:260:f6c4:df1 with SMTP id 586e51a60fabf-27759d6f08fmr64449fac.17.1724687302424; Mon, 26 Aug 2024 08:48:22 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7cd9ad5528esm7804791a12.72.2024.08.26.08.48.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Aug 2024 08:48:22 -0700 (PDT) Date: Mon, 26 Aug 2024 08:48:20 -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: <20240826084820.2c8e5055@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? > > Thanks, > Jiayu Agreed, DPDK GRO should follow Linux to avoid bugs.