Re: RFC - GRO Flowlookup Optimisation

[kumaraparameshwaran rathinavel <kumaraparamesh92@gmail.com>]

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

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 <
kumaraparamesh92@gmail.com> wrote:

>
>
> On Wed, Nov 22, 2023 at 8:44 PM 胡嘉瑜 <hujiayu.hu@foxmail.com> 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 <kumaraparamesh92@gmail.com>
>> *Date:* Wed,Nov 22,2023 2:01 PM
>> *To:* dev <dev@dpdk.org>, hujiayu.hu <hujiayu.hu@foxmail.com>
>> *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.
>>
>

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