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 13A1BA04AB; Fri, 8 Nov 2019 05:45:10 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BDC4C1BF2C; Fri, 8 Nov 2019 05:45:08 +0100 (CET) Received: from git-send-mailer.rdmz.labs.mlnx (unknown [37.142.13.130]) by dpdk.org (Postfix) with ESMTP id BEDC31BEE6 for ; Fri, 8 Nov 2019 05:45:07 +0100 (CET) From: Bing Zhao To: viacheslavo@mellanox.com Cc: orika@mellanox.com, rasland@mellanox.com, dev@dpdk.org Date: Fri, 8 Nov 2019 06:44:54 +0200 Message-Id: <1573188297-51428-1-git-send-email-bingz@mellanox.com> X-Mailer: git-send-email 1.8.3.1 Subject: [dpdk-dev] [PATCH 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" 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 | 307 +++++++++++++++++++++++----------------- 4 files changed, 224 insertions(+), 148 deletions(-) -- 1.8.3.1