DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bing Zhao <bingz@mellanox.com>
To: viacheslavo@mellanox.com
Cc: Bing Zhao <bingz@mtbc-r640-01.mtbc.labs.mlnx>,
	orika@mellanox.com, rasland@mellanox.com, dev@dpdk.org
Subject: [dpdk-dev] [PATCH v2 0/3] Reorganize resources of flow tables
Date: Fri,  8 Nov 2019 17:23:07 +0200	[thread overview]
Message-ID: <1573226590-69757-1-git-send-email-bingz@pegasus02.mtr.labs.mlnx> (raw)
In-Reply-To: <1573188297-51428-2-git-send-email-bingz@mellanox.com>

From: Bing Zhao <bingz@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


  parent reply	other threads:[~2019-11-08 15:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-08  4:44 [dpdk-dev] [PATCH " Bing Zhao
2019-11-08  4:44 ` [dpdk-dev] [PATCH 1/3] net/mlx5: reorganize flow tables with hash list Bing Zhao
2019-11-08  8:15   ` Slava Ovsiienko
2019-11-08 15:23   ` Bing Zhao [this message]
2019-11-08 15:23     ` [dpdk-dev] [PATCH v2 " Bing Zhao
2019-11-08 15:23     ` [dpdk-dev] [PATCH v2 2/3] net/mlx5: reorganize jump table resources Bing Zhao
2019-11-08 15:23     ` [dpdk-dev] [PATCH v2 3/3] net/mlx5: reorganize flow matcher resources Bing Zhao
2019-11-08 15:56     ` [dpdk-dev] [PATCH v2 0/3] Reorganize resources of flow tables Raslan Darawsheh
2019-11-08  4:44 ` [dpdk-dev] [PATCH 2/3] net/mlx5: reorganize jump table resources Bing Zhao
2019-11-08  6:38   ` Slava Ovsiienko
2019-11-08  4:44 ` [dpdk-dev] [PATCH 3/3] net/mlx5: reorganize flow matcher resources Bing Zhao
2019-11-08  8:16   ` Slava Ovsiienko
2019-11-08  6:37 ` [dpdk-dev] [PATCH 0/3] Reorganize resources of flow tables Slava Ovsiienko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1573226590-69757-1-git-send-email-bingz@pegasus02.mtr.labs.mlnx \
    --to=bingz@mellanox.com \
    --cc=bingz@mtbc-r640-01.mtbc.labs.mlnx \
    --cc=dev@dpdk.org \
    --cc=orika@mellanox.com \
    --cc=rasland@mellanox.com \
    --cc=viacheslavo@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).