GRO Enhancement Proposal

GRO Enhancement Proposal

[kumaraparameshwaran rathinavel]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

Fwd: GRO Enhancement Proposal

[kumaraparameshwaran rathinavel]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

Hi Jiyay,

Please let me know the thoughts.

Thanks,
Kumara
---------- Forwarded message ---------
From: kumaraparameshwaran rathinavel <kumaraparamesh92@gmail.com>
Date: Fri, Jul 22, 2022 at 2:05 PM
Subject: 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. 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

[-- Attachment #2: Type: text/html, Size: 3161 bytes --]