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 A496EA0547; Mon, 5 Sep 2022 19:01:26 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5AB9F400D6; Mon, 5 Sep 2022 19:01:26 +0200 (CEST) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by mails.dpdk.org (Postfix) with ESMTP id D384D40041 for ; Mon, 5 Sep 2022 19:01:24 +0200 (CEST) Received: by mail-ua1-f43.google.com with SMTP id a18so3489156uak.12 for ; Mon, 05 Sep 2022 10:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=cCQsErqeR+kIAGPF2rqQtUzh934X+inp7Q0JmTuTlVw=; b=ZVk6go5f2KdHdEXlwjeVEqfd6CjiKdpFEUvJmsAhJhB2/pWCb+QwUtS/UFLYoYxy3Q M/4WeNtxyA7P+ljv9nWjjN0S/zwW9nya+EqU0kg4885YIOOXI2TadapvE2H+ATSQVUvM kovaKPBO/wEghouCMRqQ0sKJEuAQbEagKCKdHbPxFk2daIdUx7OQdod7w39ZZH2+V2qO Lhsj6vuXSH6pRIC9p0sOD2RQ6h9l+JKqT0skQQvfQlebW9rH15PimFsJPdCn8e5sPhx5 7StDmcH14FrMBTB0OPbbQP1MuW5JnPCXN5zMcfqoOe5EMjpjgfceKcOlDPMp1nzS44eT 6P7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=cCQsErqeR+kIAGPF2rqQtUzh934X+inp7Q0JmTuTlVw=; b=OOEJzOoO6I5gtonBp+UVtG2zUEZE1CjQudxeNjGCcU6ydywduKjxESpjlxnJiWKheN iBdyBlyg4GoW9AUD7aLjoJ+X/NNXUiH96n0rpkzc+KVi7OvvPcEGXTjLEyztmHJXbfLY mHqogeW0d06uouh0pYNvLlncbtppvmeRcYMoTQqg7xRHoo55tvXRuw1fWsJzB1aXzl8Z AdQShG1iK8Y1JHlKzzXvb2Bg9IvbwKRvBb0yjnK62pwcp7DMM9qvzNdHEimumeA7VHv/ xxy8dWkKKSy6pQFdlF03jMKwJ6A21JoZPZKRzbgrjjVkWMVEnbItLhW9UShxiCmItRMx EYNA== X-Gm-Message-State: ACgBeo2iYKEsxeZGB0/Y6sYbyOSzVXHrUn/EEJHhiBbifyXVaOMNbq+/ JT4VDqKKc6p4ZbnrFnv59HfYR6p12PN47pWidlI= X-Google-Smtp-Source: AA6agR61XzUPVlk1FIlgPSAx9VYqOA2PHT6BeCvrhFCAQveCbV90EIYhKfFOTU/otb0jEsAWi3r0fEYDJBm+T2FRvXA= X-Received: by 2002:ab0:38d5:0:b0:387:5dfa:95e4 with SMTP id l21-20020ab038d5000000b003875dfa95e4mr15261222uaw.50.1662397283765; Mon, 05 Sep 2022 10:01:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: kumaraparameshwaran rathinavel Date: Mon, 5 Sep 2022 22:31:12 +0530 Message-ID: Subject: Fwd: GRO Enhancement Proposal To: "Hu, Jiayu" Cc: Thomas Monjalon , dev@dpdk.org Content-Type: multipart/alternative; boundary="00000000000093117105e7f107bd" 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 --00000000000093117105e7f107bd Content-Type: text/plain; charset="UTF-8" Hi Jiyay, Please let me know the thoughts. Thanks, Kumara ---------- Forwarded message --------- From: kumaraparameshwaran rathinavel Date: Fri, Jul 22, 2022 at 2:05 PM Subject: GRO Enhancement Proposal To: Cc: Hu, Jiayu , Ferruh Yigit Hi Everyone, I am thinking of a few enhancements to the existing GRO library and I have listed them below, 1. The current implementation for the TCP in GRO disregards the PSH flag and delivers it immediately in the current burst. But this would lead to reordering of packets if there were ACK packets subjected to GRO. The peer could potentially think that these are out of order packets. I think this was done this way, keeping timer mode GRO in mind and the PSH packet was sent in the current burst. But can we enhance it in such a way that we merge the packet with PSH flag to the existing flow and mark the item in the table to be flushed immediately when rte_gro_timeout_flush is invoked. If we receive a packet with PSH flag set and there is no matching flow existing, we could flush the packet immediately. This would not cause out of order packets in an ideal case. It can be assumed that in ideal cases the rte_gro_timeout_flush would be invoked periodically and hence we have solved the packet reordering issues. Also in most of the cases, the TCP timestamp of the PSH packet would be the same as that of the previous ACK packets that are subjected to the GRO. I understand that we do not want to delay the packet with PSH flag set, but in general the PSH flag is set on the last segment of the packet, which means that the packets upto the PSH flag should be delivered immediately. But in the existing library we send the packet only with the PSH flag set. This could be handled for the static (inline mode) of GRO as well. 2. The flow matching algorithm currently iterates over all the existing flows to check for a match. This could be changed to a HASH based lookup based on the TUPLE similar to the implementation in Linux Kernel, because with Timer mode GRO and if there are higher number of flows this would become costly. Also many applications in userspace would maintain a flowtable for the lookup based on Hash or Tree, from GRO layer can we provide an option where rather than using the default flow matching algorithm, we use the application's flow matching algorithm. Please let me know your thoughts on the above proposal. Thanks, Kumara Parameshwaran --00000000000093117105e7f107bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jiyay,

Ple= ase let me know the thoughts.

Thanks,
Kumara
---------- Forwarded message ---------
From: kumaraparameshwaran rathinavel <kumaraparamesh= 92@gmail.com>
Date: Fri, Jul 22, 2022 at 2:05 PM
Subjec= t: GRO Enhancement Proposal
To: <dev= @dpdk.org>
Cc: Hu, Jiayu <jiayu.hu@intel.com>, Ferruh Yigit <ferruh.yigit@intel.com>


Hi Everyone,

I am thinking of a few = enhancements to the existing GRO library and I have listed them below,

  1. The current implementation for the TCP in GRO = disregards the PSH flag and delivers it immediately in the current burst. B= ut this would lead to reordering of packets if there were ACK packets subje= cted to GRO. The peer could potentially think that these are out of order p= ackets. I think this was done this way, keeping timer mode GRO in mind and = the PSH packet was sent in the current burst. But can we enhance it in such= a way that we merge the packet with PSH flag to the existing flow and mark= the item in the table to be flushed immediately when rte_gro_timeout_flush= is invoked. If we receive a packet with PSH flag set and there is no match= ing flow existing, we could flush the packet immediately. This would not ca= use out of order packets in an ideal case. It can be assumed that in ideal = cases the rte_gro_timeout_flush would be invoked periodically and hence we = have solved the packet reordering issues. Also in most of the cases, the TC= P timestamp of the PSH packet would be the same as that of the previous ACK= packets that are subjected to the GRO. I understand that we do not want to= delay the packet with PSH flag set, but in general the PSH flag is set on = the last segment of the packet, which means that the packets upto the PSH f= lag should be delivered immediately. But in the existing library we send th= e packet only with the PSH flag set. This could be handled for the static (= inline mode) of GRO as well.
  2. The flow matching algorithm curre= ntly iterates over all the existing flows to check for a match. This could = be changed to a HASH based lookup based on the TUPLE similar to the impleme= ntation in Linux Kernel, because with Timer mode GRO and if there are highe= r number of flows this would become costly. Also many applications in users= pace would maintain a flowtable for the lookup based on Hash or Tree, from = GRO layer can we provide an option where rather than using the default flow= matching algorithm, we use the application's flow matching algorithm. =
Please let me know your thoughts on the above proposal. =

Thanks,
Kumara Parameshwaran
--00000000000093117105e7f107bd--