[dpdk-dev] [PATCH v2 0/3] Reorganize resources of flow tables

[Raslan Darawsheh]

Hi,
> -----Original Message-----
> From: Bing Zhao <bingz at mellanox.com>
> Sent: Friday, November 8, 2019 5:23 PM
> To: Slava Ovsiienko <viacheslavo at mellanox.com>
> Cc: Bing Zhao <bingz at mtbc-r640-01.mtbc.labs.mlnx>; Ori Kam
> <orika at mellanox.com>; Raslan Darawsheh <rasland at mellanox.com>;
> dev at dpdk.org
> Subject: [PATCH v2 0/3] Reorganize resources of flow tables
> 
> From: Bing Zhao <bingz at mtbc-r640-01.mtbc.labs.mlnx>
> 
> 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
Added missing:
Acked-by: Viacheslav Ovsiienko <viacheslavo at mellanox.com>
Removed wrong Signed-of-by signature.

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh