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 DB474A0032; Fri, 22 Jul 2022 10:35:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A7ED94021E; Fri, 22 Jul 2022 10:35:44 +0200 (CEST) Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by mails.dpdk.org (Postfix) with ESMTP id A443D40156 for ; Fri, 22 Jul 2022 10:35:43 +0200 (CEST) Received: by mail-vk1-f174.google.com with SMTP id n15so1777119vkk.8 for ; Fri, 22 Jul 2022 01:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=cwdHCoYtuNmUH3c/Teo02EOvaNj23BFyYdRTN0low5E=; b=BCUG7XY7xxaiNJVWMdjnVT43oTexCczI8v2HuMey6iz7X8bvMB0eVES9wnWtiVc1KA E6zYT8FR05JH+xTTwI2b4mEl7lUVBdrlZbP0y6+1/fME3tlMo3B7mCMZf1YM2xjd2v6B oATyNeOW+tTaHEXzg3jzAtZfbW9YD5jnspsB1Ejqw/Ydh0/FsksNZiqQTDpg+phJ1fnC 2A0U7iDmOEqKrtReHmrN2C1grC6wk5Ej4Ccxc9bxdUoECTrIdO79jmB6SOJsLLl1LRgt ure+O2FSyn/pOous09O3KC5hffRYb2+epEzm6KOo+KzOk6eChstQPU1XZ2R+H0NStAwB x3gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=cwdHCoYtuNmUH3c/Teo02EOvaNj23BFyYdRTN0low5E=; b=oVuoaamWNIBnRvN47CkG4N2BNRGb1vmZzlzhgdKaQhbLFlT8RZfmMOizlcMZnSr8ZN oC4GwXKNHvhomuTPW3XLQiWs0NGbWs9Qa8a1xgs8tHPr+7e8u/Av87vVF+2s2p9i4KD5 nWRDVZVJ8E7PMXVyS2fBiCcMOhOk4YAn1CHvDOX3V9CnjoeODLn6fw87r9W8MNjyV+3/ qXOadudaPY5/eOcCYMkc4eXEfF3WkMCb6/usuGCrmIqGXF6ZcrFX7udw/Hq1UVrQ0glz RRlmeGv3EdUIEbn3L2z46RJxEC1T0i0JnIA/Chgdrnw6t7rVySu9yYXlg8dm0lNVS35N bXWw== X-Gm-Message-State: AJIora8jtgZnowjTPm6LIRSd+idBWAVTbwB93rBJWrRpK0LrL/aNpTdI U9TEe4OCyywRLE1rB/694B2E54bM1d2yFcHr88UnhTD0RsY= X-Google-Smtp-Source: AGRyM1sOa1U/inxh+aS0Lz/cDYaKIJiCAhqnbkk7cwPP4ofpOIwAvntZWn4JyZtWAWPDsqq+re/n+/WdGVqAXxwPTEU= X-Received: by 2002:a1f:7247:0:b0:375:28f7:9afc with SMTP id n68-20020a1f7247000000b0037528f79afcmr734034vkc.28.1658478942400; Fri, 22 Jul 2022 01:35:42 -0700 (PDT) MIME-Version: 1.0 From: kumaraparameshwaran rathinavel Date: Fri, 22 Jul 2022 14:05:30 +0530 Message-ID: Subject: GRO Enhancement Proposal To: dev@dpdk.org Cc: "Hu, Jiayu" , Ferruh Yigit Content-Type: multipart/alternative; boundary="0000000000003ab4a605e460b816" 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 --0000000000003ab4a605e460b816 Content-Type: text/plain; charset="UTF-8" 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 --0000000000003ab4a605e460b816 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Everyone,

I am think= ing of a few enhancements to the existing GRO library and I have listed the= m below,

  1. The current implementation for th= e TCP in GRO disregards the PSH flag and delivers it immediately in the cur= rent 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 o= ut 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 enhan= ce 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 ther= e 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 t= hat 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 d= o not want to delay the packet with PSH flag set, but in general the PSH fl= ag is set on the last segment of the packet, which means that the packets u= pto the PSH flag should be delivered immediately. But in the existing libra= ry 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 al= gorithm 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 t= o the implementation in Linux Kernel, because with Timer mode GRO and if th= ere are higher number of flows this would become costly. Also many applicat= ions in userspace would maintain a flowtable for the lookup based on Hash o= r Tree, from GRO layer can we provide an option where rather than using the= default flow matching algorithm, we use the application's flow matchin= g algorithm.
Please let me know your thoughts on the abo= ve proposal.

Thanks,
Kumara Parames= hwaran
--0000000000003ab4a605e460b816--