<div dir="auto">Hi Jiayu, Thomas,</div><div dir="auto"><br></div><div dir="auto">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.  </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Please let me know your thoughts on this. </div><div dir="auto"><br></div><div dir="auto">Thanks.</div><div dir="auto">Kumara </div><div dir="auto"><br></div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 22 Nov 2023 at 9:06 PM, kumaraparameshwaran rathinavel <<a href="mailto:kumaraparamesh92@gmail.com">kumaraparamesh92@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 22, 2023 at 8:44 PM 胡嘉瑜 <<a href="mailto:hujiayu.hu@foxmail.com" target="_blank">hujiayu.hu@foxmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="min-height:22px;margin-bottom:8px">Hi Kumara,</div><div style="min-height:22px;margin-bottom:8px"><br></div><div style="min-height:22px;margin-bottom:8px">It is a good idea. You can send the code and I will help to review.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Thanks Jiyau. Will try to get out a PR in few days. <br></blockquote></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="min-height:22px;margin-bottom:8px"><br></div><div style="min-height:22px;margin-bottom:8px">Thanks,</div><div style="min-height:22px;margin-bottom:8px">Jiayu</div><div id="m_97921188080866262m_446969966628184478QQMailSignature" aria-hidden="true"><hr style="margin:0px 0px 10px;border-width:0px 0px 1px;border-style:none none solid;height:0px;line-height:0;font-size:0px;padding:20px 0px 0px;width:50px;border-color:currentcolor currentcolor rgb(230,232,235)">发自我的iPhone</div><div id="m_97921188080866262m_446969966628184478original-content"><br><br><div><div style="font-size:70%;padding:2px 0px">------------------ Original ------------------</div><div style="font-size:70%;background:0% 0% repeat rgb(240,240,240);padding:8px;border-radius:4px;color:rgb(33,33,33)"><div><b>From:</b> kumaraparameshwaran rathinavel <<a href="mailto:kumaraparamesh92@gmail.com" target="_blank">kumaraparamesh92@gmail.com</a>></div><div><b>Date:</b> Wed,Nov 22,2023 2:01 PM</div><div><b>To:</b> dev <<a href="mailto:dev@dpdk.org" target="_blank">dev@dpdk.org</a>>, <a href="http://hujiayu.hu" target="_blank">hujiayu.hu</a> <<a href="mailto:hujiayu.hu@foxmail.com" target="_blank">hujiayu.hu@foxmail.com</a>></div><div><b>Subject:</b> Re: RFC - GRO Flowlookup Optimisation</div></div></div><br><div dir="ltr"><div>Hi Folks,<br></div><div><br></div><div>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. <br></div><div><br></div><div>Thanks,</div><div>Kumara. <br></div></div>

</div></blockquote></div></div>
</blockquote></div></div>