From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A973343382; Wed, 22 Nov 2023 16:37:10 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 98B5C402E8; Wed, 22 Nov 2023 16:37:10 +0100 (CET) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by mails.dpdk.org (Postfix) with ESMTP id 9FB0C4028C for ; Wed, 22 Nov 2023 16:37:09 +0100 (CET) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-d9b9adaf291so6103842276.1 for ; Wed, 22 Nov 2023 07:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700667429; x=1701272229; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RKQdQBXqOVjS+32ut00hITFwSxDx8vJ8iQSZJY+rNBs=; b=HNbFDSGzlicLjksFPuKV53jC5PsLJIhmcFCBZ1xoeOUqQOlXsqak0+LD3G3R+cUsL9 oDRsvKIM/pIm04efB7lPNzkMggMWAYgLavif4JZkC1T5qtGQyy60PgyymZRdJ4Hu7f9u 73rlLUJNV8f4iuFmadXos45epxuI4+NYz/BsKvRbHFFXEhfwV+gA6Fx08CSC3eGz3edj TZmbBAvy32BvZnSG92Pt4hDwjFnpWpzf06h1mKBr6qAyWkhXEn3W4hYh2k8VYrWQC3UF S6g7xkJsyqzwgewurFxacrhNaE+W32pr+Jo+IsD1l2qKm7SpIkIkmi1K7TE0cKGTDuVL K2Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700667429; x=1701272229; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RKQdQBXqOVjS+32ut00hITFwSxDx8vJ8iQSZJY+rNBs=; b=W5378LnmtwqwZCyTioduw2wfibBEnfbcLQ2C/uJNZl0mmUyzj2AljRg5vRQ2t8JaDd OKgRU+flG3BA5OIMg4HvZw7qd/y5w/39/Olh8V0+2kKyWo0m9Np4N88NuhYbIP3o3zH+ ihwPM+xXvg5XoXbaF1eQBDchbSx9vOn5265CP2LsVDOYcY0XfqvaoB1kloM10n22Qvz0 PcG7ZcB+e/3Cyu9BJF3DOQ8IzE84rUYCQCtjfJRJWr9cJNWG5mFhImrxN30iQxwACQGH BSdpHH7DXQKSvc2pdIWWwAakIFKtQ8L7LIPep0lHR4nvtMhxxFvgBOQ4uSWaYUyNzyLf Bqnw== X-Gm-Message-State: AOJu0YxCnYxXhzX3q6QbxoVybspcB2P3bntjVY/5qFYJye95/EfSnWoE UpobRecnZrZNcov/hzyM3AHyXdybzo77W2BzqF9U3xN7I/A= X-Google-Smtp-Source: AGHT+IHFlPUqirCe9ekCJpTHYFyRvS0C8hle+0MI4Ov+65TrXJlmkKUIG6ZtS0tzOambIMu2RVu4BYL02VloZ4hCob4= X-Received: by 2002:a25:1102:0:b0:db4:4df:8c15 with SMTP id 2-20020a251102000000b00db404df8c15mr1715713ybr.34.1700667428860; Wed, 22 Nov 2023 07:37:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: kumaraparameshwaran rathinavel Date: Wed, 22 Nov 2023 21:06:57 +0530 Message-ID: Subject: Re: RFC - GRO Flowlookup Optimisation To: =?UTF-8?B?6IOh5ZiJ55Gc?= Cc: dev Content-Type: multipart/alternative; boundary="000000000000fa7920060abf7d87" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000fa7920060abf7d87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 22, 2023 at 8:44=E2=80=AFPM =E8=83=A1=E5=98=89=E7=91=9C 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 > ------------------------------ > =E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84iPhone > > > ------------------ 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 version of flow lookup where eac= h > 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 th= e > rte_hash table implementation in DPDK. There could be a hash table for ea= ch > 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 le= t > me know your thoughts. > > Thanks, > Kumara. > --000000000000fa7920060abf7d87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 22, 2023 at 8:44=E2=80=AF= PM =E8=83=A1=E5=98=89=E7=91=9C <hujiayu.hu@foxmail.com> wrote:
Hi= Kumara,

It is a good idea. You can s= end the code and I will help to review.
Thanks Jiyau. Will try to get out a PR in few days.
<= /blockquote>

Thanks,
Jiayu
=E5=8F=91=E8=87=AA=E6=88=91=E7=9A=84iPhon= e


------------------ Original --------= ----------
From: kumarapar= ameshwaran rathinavel <kumaraparamesh92@gmail.com>
Date: We= d,Nov 22,2023 2:01 PM
Subjec= t: Re: RFC - GRO Flowlookup Optimisation

Hi Folks,

The current GRO code u= ses an unoptimised version of flow lookup where each flow in the table is i= terated over during the flow matching process. For a rte_gro_reassemble_bur= st 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 C= PU utilisation during throughput tests. The proposal here is to use a Hash = based flowtable which could make use of the=C2=A0 rte_hash table implementa= tion in DPDK. There could be a hash table for each of the GRO types. The lo= okup 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 wou= ld work on an initial patch set. Please let me know your thoughts.

Thanks,
Kumara.
--000000000000fa7920060abf7d87--