Re: RFC - GRO Flowlookup Optimisation

2023-11-22 Thread kumaraparameshwaran rathinavel
Phone > > > -- Original -- > *From:* kumaraparameshwaran rathinavel > *Date:* Wed,Nov 22,2023 2:01 PM > *To:* dev , hujiayu.hu > *Subject:* Re: RFC - GRO Flowlookup Optimisation > > Hi Folks, > > The current GRO code uses an unoptimised versi

Re: RFC - GRO Flowlookup Optimisation

2023-11-22 Thread kumaraparameshwaran rathinavel
On Wed, Nov 22, 2023 at 4:05 PM Ferruh Yigit wrote: > On 11/22/2023 6:01 AM, kumaraparameshwaran rathinavel wrote: > > 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 rt

Re: RFC - GRO Flowlookup Optimisation

2023-11-22 Thread 胡嘉瑜
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

Re: RFC - GRO Flowlookup Optimisation

2023-11-22 Thread Ferruh Yigit
On 11/22/2023 6:01 AM, kumaraparameshwaran rathinavel wrote: > 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

RFC - GRO Flowlookup Optimisation

2023-11-21 Thread kumaraparameshwaran rathinavel
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 time