Re: RFC - GRO Flowlookup Optimisation

[kumaraparameshwaran rathinavel <kumaraparamesh92@gmail.com>]

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

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: 2985 bytes --]