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 2337643397; Wed, 22 Nov 2023 07:01:49 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E4C704014F; Wed, 22 Nov 2023 07:01:48 +0100 (CET) Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) by mails.dpdk.org (Postfix) with ESMTP id 1BCE340144 for ; Wed, 22 Nov 2023 07:01:47 +0100 (CET) Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5875c300becso3867201eaf.0 for ; Tue, 21 Nov 2023 22:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700632906; x=1701237706; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3sf6gnn/3zcfZuhRmp9LMofffATzwKO1tIFQeC9J58w=; b=Da/HXKcYlnIWcIkKfcTdOnQ+XI7AaxeEay0OYEYrqx4h6V7JhFBRQi1/vUK1jryEAi ftNwr+jWox3r29PyDP8YSjZ3OKTo2pE+5F33AsTtH3yEHFVAii04ldToLPOUWl3xCcPw 6LnJZdTWgPqCjPtHiF8TnYKScb4vmZSPhc6fv+fWuZ/J7ZGRR0V8jx7J8ixUV+mApb2p AtoVuFH5Gu2vNVkw959T1/uQPXj86EOWjJVQy7NlTdhAq9B3WJdKTYC0AlMTJjh5+T8p ctO0Ylcs1vx5ZBSkve+RNEx7i4BVSrR9MSc3GJWpmJL/PJRefmcYzGZC0+l+uWQaUn8x h5MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700632906; x=1701237706; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3sf6gnn/3zcfZuhRmp9LMofffATzwKO1tIFQeC9J58w=; b=gxTmaRRBzbpd04x3AQYPrmCDWO95ImbQtf9UZatuO5Lf2DA38pPviDSfHoUCIm1XzV nrICHDchonqgKyb0NyO4x0oOKCrFNg2fCzsCEPrTzGK6niGFLfotuht1aTv4EZ32DdMJ YTvSzcL6CKDfsPlO9MdK8EJu7FLdfLB3zCM43kjns5Zvahw92HTP1nedPjYeSNsFsIrL I8W335ARriRhczOvS5bDYiPGvLdPtwcMMa65zhZDc/abU7okwCKOakCEMo9OtB5lD+xl v0PbLzI3pvhxIxdpCqXCHTuPLzlWqVDUkScUyZj8qGn2u2a1+fN0CAVbb3HUQ3GhgVZw RlXQ== X-Gm-Message-State: AOJu0Yy9doC6F0/rqgQBSsjoFaSBAGKQ3JtZMZU8Tn+ipiV+6+5OS3yj ooKNcikQU3y68kmg0XJ6D4JRJCc43tGkriqnn/JG8ipSStk= X-Google-Smtp-Source: AGHT+IGMg73eatQ+MlvPEjO1M80KEMJhhVHcfOfm9vvpR1zx9CPznmR7zlLY0V+3LbExuF+V6a3VvhrTD1BPmuhW2z4= X-Received: by 2002:a05:6358:5915:b0:16d:aead:f764 with SMTP id g21-20020a056358591500b0016daeadf764mr1649409rwf.12.1700632906157; Tue, 21 Nov 2023 22:01:46 -0800 (PST) MIME-Version: 1.0 From: kumaraparameshwaran rathinavel Date: Wed, 22 Nov 2023 11:31:35 +0530 Message-ID: Subject: RFC - GRO Flowlookup Optimisation To: dev@dpdk.org, hujiayu.hu@foxmail.com Content-Type: multipart/alternative; boundary="00000000000043d0f2060ab774ce" 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 --00000000000043d0f2060ab774ce Content-Type: text/plain; charset="UTF-8" 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. --00000000000043d0f2060ab774ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Folks,

The current GR= O code uses an unoptimised version of flow lookup where each flow in the ta= ble is iterated over during the flow matching process. For a rte_gro_reasse= mble_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=C2=A0 rte_hash table im= plementation 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 ty= pes. If there is a consensus that this could have a better performance impa= ct I would work on an initial patch set. Please let me know your thoughts. =

Thanks,
Kumara.
--00000000000043d0f2060ab774ce--