DPDK patches and discussions
 help / color / mirror / Atom feed
* RFC - GRO Flowlookup Optimisation
@ 2023-11-22  6:01 kumaraparameshwaran rathinavel
  2023-11-22 10:35 ` Ferruh Yigit
  0 siblings, 1 reply; 5+ messages in thread
From: kumaraparameshwaran rathinavel @ 2023-11-22  6:01 UTC (permalink / raw)
  To: dev, hujiayu.hu

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

Hi Folks,

The current GRO code uses an unoptimised version of flow lookup where each
flow in the table is iterated over during the flow matching process. For a
rte_gro_reassemble_burst in lightweight mode this would not cause much of
an impact. But with rte_gro_reassemble which is done with a timeout
interval, this causes higher CPU utilisation during throughput tests. The
proposal here is to use a Hash based flowtable which could make use of the
rte_hash table implementation in DPDK. There could be a hash table for each
of the GRO types. The lookup function and the key could be different for
each one of the types. If there is a consensus that this could have a
better performance impact I would work on an initial patch set. Please let
me know your thoughts.

Thanks,
Kumara.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: RFC - GRO Flowlookup Optimisation
@ 2023-11-22 15:14 胡嘉瑜
  2023-11-22 15:36 ` kumaraparameshwaran rathinavel
  0 siblings, 1 reply; 5+ messages in thread
From: 胡嘉瑜 @ 2023-11-22 15:14 UTC (permalink / raw)
  To: kumaraparameshwaran rathinavel, dev

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

Hi Kumara,


It is a good idea. You can send the code and I will help to review.


Thanks,
Jiayu

发自我的iPhone


------------------ Original ------------------
From: kumaraparameshwaran rathinavel <kumaraparamesh92@gmail.com&gt;
Date: Wed,Nov 22,2023 2:01 PM
To: dev <dev@dpdk.org&gt;, hujiayu.hu <hujiayu.hu@foxmail.com&gt;
Subject: Re: RFC - GRO Flowlookup Optimisation



Hi Folks,



The current GRO code uses an unoptimised version of flow lookup where each flow in the table is iterated over during the flow matching process. For a rte_gro_reassemble_burst in lightweight mode this would not cause much of an impact. But with rte_gro_reassemble which is done with a timeout interval, this causes higher CPU utilisation during throughput tests. The proposal here is to use a Hash based flowtable which could make use of the&nbsp; rte_hash table implementation in DPDK. There could be a hash table for each of the GRO types. The lookup function and the key could be different for each one of the types. If there is a consensus that this could have a better performance impact I would work on an initial patch set. Please let me know your thoughts. 



Thanks,
Kumara.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-11-22 15:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-22  6:01 RFC - GRO Flowlookup Optimisation kumaraparameshwaran rathinavel
2023-11-22 10:35 ` Ferruh Yigit
2023-11-22 15:35   ` kumaraparameshwaran rathinavel
2023-11-22 15:14 胡嘉瑜
2023-11-22 15:36 ` 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).