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

[Slava Ovsiienko <viacheslavo@mellanox.com>]

> -----Original Message-----
> From: Bing Zhao <bingz@mellanox.com>
> Sent: Friday, November 8, 2019 6:45
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: Ori Kam <orika@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>; dev@dpdk.org
> Subject: [PATCH 0/3] Reorganize resources of flow tables
> 
> 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
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>