RFC - GRO Flowlookup Optimisation

RFC - GRO Flowlookup Optimisation

[kumaraparameshwaran rathinavel]

[-- 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 --]

Re: RFC - GRO Flowlookup Optimisation

[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 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.
> 


Hi Kumara,

Your proposal looks reasonable to me, I think it worth to try.
cc'ed techboard for more comment.

Do you have any performance measurement with the existing code? To have
it helps to evaluate impact of the change.

Re: RFC - GRO Flowlookup Optimisation

[kumaraparameshwaran rathinavel]

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

On Wed, Nov 22, 2023 at 4:05 PM Ferruh Yigit <ferruh.yigit@amd.com> 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 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.
> >
>
>
> Hi Kumara,
>
> Your proposal looks reasonable to me, I think it worth to try.
> cc'ed techboard for more comment.
>
>> Thanks Ferruh - Sure I will get a initial patch set with TCP/IPv4 GRO
>> type.
>>
>
> Do you have any performance measurement with the existing code? To have
> it helps to evaluate impact of the change.
>
>> I did some testing sometime back and the observations were that on a
>> 10Gbps link, the throughput value with iperf testing
>> of unoptimised and optimised were almost the same, but the CPU
>> conservation was upto 30-35%. So any tests running in
>> parallel like imix kind of traffic would definitely have better results.
>> I will try to profile the two cases with some performance impacting
>> results.
>>
>

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

Re: RFC - GRO Flowlookup Optimisation

[胡嘉瑜]

[-- 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 --]

Re: RFC - GRO Flowlookup Optimisation

[kumaraparameshwaran rathinavel]

[-- 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 --]