* GRO Enhancement Proposal
@ 2022-07-22 8:35 kumaraparameshwaran rathinavel
2022-09-05 17:01 ` Fwd: " kumaraparameshwaran rathinavel
0 siblings, 1 reply; 2+ messages in thread
From: kumaraparameshwaran rathinavel @ 2022-07-22 8:35 UTC (permalink / raw)
To: dev; +Cc: Hu, Jiayu, Ferruh Yigit
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Fwd: GRO Enhancement Proposal
2022-07-22 8:35 GRO Enhancement Proposal kumaraparameshwaran rathinavel
@ 2022-09-05 17:01 ` kumaraparameshwaran rathinavel
0 siblings, 0 replies; 2+ messages in thread
From: kumaraparameshwaran rathinavel @ 2022-09-05 17:01 UTC (permalink / raw)
To: Hu, Jiayu; +Cc: Thomas Monjalon, dev
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-09-05 17:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-22 8:35 GRO Enhancement Proposal kumaraparameshwaran rathinavel
2022-09-05 17:01 ` Fwd: " kumaraparameshwaran rathinavel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).