From patchwork Mon May 17 07:22:48 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: taoyunxiang X-Patchwork-Id: 1479273 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=openvswitch.org (client-ip=140.211.166.137; helo=smtp4.osuosl.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4Fk9bl4Z2Kz9sWW for ; Mon, 17 May 2021 17:23:47 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1EDB540451; Mon, 17 May 2021 07:23:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3gOE-CavTTw; Mon, 17 May 2021 07:23:41 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTP id 3C1954033C; Mon, 17 May 2021 07:23:40 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id F04BDC000E; Mon, 17 May 2021 07:23:39 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@lists.linuxfoundation.org Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 63C9EC0001 for ; Mon, 17 May 2021 07:23:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3E123400DD for ; Mon, 17 May 2021 07:23:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twTCHKtJJLzn for ; Mon, 17 May 2021 07:23:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by smtp2.osuosl.org (Postfix) with ESMTP id 74E1D400C4 for ; Mon, 17 May 2021 07:23:33 +0000 (UTC) Received: from spf.mail.chinamobile.com (unknown[172.16.121.15]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea60a219d7626-7255e; Mon, 17 May 2021 15:23:05 +0800 (CST) X-RM-TRANSID: 2eea60a219d7626-7255e X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from yun.localdomain (unknown[112.25.154.146]) by rmsmtp-syy-appsvr08-12008 (RichMail) with SMTP id 2ee860a219d56cb-47d8c; Mon, 17 May 2021 15:23:02 +0800 (CST) X-RM-TRANSID: 2ee860a219d56cb-47d8c From: Tao YunXiang To: dev@openvswitch.org Date: Mon, 17 May 2021 15:22:48 +0800 Message-Id: <20210517072248.1743-1-taoyunxiang@cmss.chinamobile.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <8> References: <8> Cc: Tao YunXiang Subject: [ovs-dev] [PATCH v2] Improve concurrency by adjust flow-limit X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: ovs-dev-bounces@openvswitch.org Sender: "dev" OVS uses a set of gentle mechanisms to control the number of flows in datapath. However, it is difficult for the number of datapath flows to reach a high level in a short time. Through some tests with Apache benchmark, I found the point is that the value of flow-limit increases too slowly, but decreases very quickly. This change has two improvements. One is the flow-limit will adjust more linearly. The other one is, when the duration is small, the flow-limit will increase faster. Through this change, the test result of Apache benchmark can reach 12k from 5k, the test command is as follows: ab -n 200000 -c 500 -r http://1.1.1.2/ v1->v2: Make flow-limit changes linearly. Add a limitation to make flow_limit won't overflow UINT_MAX. Signed-off-by: Tao YunXiang Cc: Ben Pfaff --- ofproto/ofproto-dpif-upcall.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index ccf97266c..805409165 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -963,14 +963,20 @@ udpif_revalidator(void *arg) duration = MAX(time_msec() - start_time, 1); udpif->dump_duration = duration; - if (duration > 2000) { - flow_limit /= duration / 1000; - } else if (duration > 1300) { - flow_limit = flow_limit * 3 / 4; - } else if (duration < 1000 && - flow_limit < n_flows * 1000 / duration) { - flow_limit += 1000; + + /* Use duration as a reference, adjust the value of flow_limit, + * when the duration is short, increase the flow_limit, and vice + * versa. The purpose of using multiple conversions between int + * and float is to make the flow_limit change more linear. */ + + if (duration >= 1000) { + flow_limit = (int) ((float) (flow_limit) / (duration / 1000.0)); + } else if (flow_limit * (1000.0 / duration) >= UINT_MAX) { + flow_limit = ofproto_flow_limit; + } else { + flow_limit = (int) (flow_limit * (1000.0 / duration)); } + flow_limit = MIN(ofproto_flow_limit, MAX(flow_limit, 1000)); atomic_store_relaxed(&udpif->flow_limit, flow_limit);