From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2C3EDA04B4; Fri, 8 Nov 2019 16:23:38 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C4F591C247; Fri, 8 Nov 2019 16:23:20 +0100 (CET) Received: from mellanox.co.il (mail-il-dmz.mellanox.com [193.47.165.129]) by dpdk.org (Postfix) with ESMTP id C8B4A1C224 for ; Fri, 8 Nov 2019 16:23:12 +0100 (CET) Received: from Internal Mail-Server by MTLPINE1 (envelope-from bingz@mellanox.com) with ESMTPS (AES256-SHA encrypted); 8 Nov 2019 17:23:10 +0200 Received: from pegasus02.mtr.labs.mlnx. (pegasus02.mtr.labs.mlnx [10.210.16.122]) by labmailer.mlnx (8.13.8/8.13.8) with ESMTP id xA8FNAwr023982; Fri, 8 Nov 2019 17:23:10 +0200 Received: from pegasus02.mtr.labs.mlnx. (localhost.localdomain [127.0.0.1]) by pegasus02.mtr.labs.mlnx. (8.14.7/8.14.7) with ESMTP id xA8FNALp069793; Fri, 8 Nov 2019 17:23:10 +0200 Received: (from bingz@localhost) by pegasus02.mtr.labs.mlnx. (8.14.7/8.14.7/Submit) id xA8FNAnL069792; Fri, 8 Nov 2019 17:23:10 +0200 From: Bing Zhao To: viacheslavo@mellanox.com Cc: Bing Zhao , orika@mellanox.com, rasland@mellanox.com, dev@dpdk.org Date: Fri, 8 Nov 2019 17:23:07 +0200 Message-Id: <1573226590-69757-1-git-send-email-bingz@pegasus02.mtr.labs.mlnx> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1573188297-51428-2-git-send-email-bingz@mellanox.com> References: <1573188297-51428-2-git-send-email-bingz@mellanox.com> Subject: [dpdk-dev] [PATCH v2 0/3] Reorganize resources of flow tables X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Bing Zhao Number of flow tables is limited by the memory resource, and the index could be to as large as 2^^32 - 1. In the past, the flow tables are organized by arrays, and this organization has some advantages and disadvantages. The lookup for the table resource from a linear array is quite fast, the ID could be used as the index in the array. But it will cost some extra memory resource after system bring up and if only a small number of tables are created. In the meanwhile, since we could not create the array with a huge number, so the maximal index of the table is limited and it is unreasonable. If we change the array into some other tables, like some open addressing hash table, the static memory cost is still to huge. But the index of the table limitation could be get rid of. But in the meanwhile, it will introduce some new issue that two tables with different ID may generate the same address index in the table. Then it will degrade the performance of the lookup, creating and deleting. Moreover, sometimes it will cause a failure if the collisions rate are too heavy. Then the simple hash list is used as the first step to get rid of this limitations. The only static memory over head is array of the LIST HEADs. In the next step, we could use some extendable hash tables for this. This will of course introduce some performance degradation when lookup, creating and removing tables in the lists if there are a lot of tables created in the system. We need to trade off among the functionality, memory and performance. Some other resources are associated with each flow tables and not global, like flow matchers and jump table object used by driver. They could also be reorganized and put into the flow table resources structure. Then the lookup process of these resources will be speeded up significantly. Bing Zhao (3): net/mlx5: reorganize flow tables with hash list net/mlx5: reorganize jump table resources net/mlx5: reorganize flow matcher resources drivers/net/mlx5/mlx5.c | 16 ++ drivers/net/mlx5/mlx5.h | 25 ++-- drivers/net/mlx5/mlx5_flow.h | 24 ++- drivers/net/mlx5/mlx5_flow_dv.c | 316 +++++++++++++++++++++++----------------- 4 files changed, 230 insertions(+), 151 deletions(-) -- 1.8.3.1