Hi Jiayu, Thomas, I had recently posted a patch to do flow operations based on hash for the timer mode GRO. Stephen had started reviewing it. The implementation would not work for the burst mode GRO where we try to coalesce the packets received in single burst. To make this work for the burst mode, it’s not straightforward as the tables are just declared in the stack and the new hash based implementation cannot fit in to this design easily.
To address this and keep it simple, can we have just one mode where we try do GRO as long as the burst never returns 0 or we receive a packet with flags like FIN/PSH. I think this is similar to kernel GRO as well. We should have a timer / logic to periodically to scavenge to flush the flows which is the current timer based implementation. Please let me know your thoughts on this. Thanks. Kumara On Wed, 22 Nov 2023 at 9:06 PM, kumaraparameshwaran rathinavel < [email protected]> wrote: > > > On Wed, Nov 22, 2023 at 8:44 PM 胡嘉瑜 <[email protected]> wrote: > >> Hi Kumara, >> >> It is a good idea. You can send the code and I will help to review. >> >>> Thanks Jiyau. Will try to get out a PR in few days. >>> >> >> Thanks, >> Jiayu >> ------------------------------ >> 发自我的iPhone >> >> >> ------------------ Original ------------------ >> *From:* kumaraparameshwaran rathinavel <[email protected]> >> *Date:* Wed,Nov 22,2023 2:01 PM >> *To:* dev <[email protected]>, hujiayu.hu <[email protected]> >> *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 >> 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. >> >
