Hi, > -----Original Message----- > From: Bing Zhao <bi...@mellanox.com> > Sent: Friday, November 8, 2019 5:23 PM > To: Slava Ovsiienko <viachesl...@mellanox.com> > Cc: Bing Zhao <bi...@mtbc-r640-01.mtbc.labs.mlnx>; Ori Kam > <or...@mellanox.com>; Raslan Darawsheh <rasl...@mellanox.com>; > dev@dpdk.org > Subject: [PATCH v2 0/3] Reorganize resources of flow tables > > From: Bing Zhao <bi...@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 <viachesl...@mellanox.com> Removed wrong Signed-of-by signature.
Series applied to next-net-mlx, Kindest regards, Raslan Darawsheh
