DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bing Zhao <bingz@mellanox.com>
To: Shahaf Shuler <shahafs@mellanox.com>,
	Matan Azrad <matan@mellanox.com>,
	Slava Ovsiienko <viacheslavo@mellanox.com>
Cc: Ori Kam <orika@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] [RFC] net/mlx5: move to non-cached mode for flow rules
Date: Wed, 11 Dec 2019 07:53:29 +0000	[thread overview]
Message-ID: <VI1PR05MB4192E3B248D056F7CF6B3333DD5A0@VI1PR05MB4192.eurprd05.prod.outlook.com> (raw)

In the current PMD implementation, all the flow rules' related information is
stored by default, like the table resources, matchers and actions and so on that
are already translated into the hardware descriptions via the interfaces. When
restarting a device after stopping it, all the flow rules will be retained and
reapplied to the NIC automatically. Handling for each packet will remain the
same after the device restarting. And this is what we are talking about "cached
mode" for flow rules.

There are also two disadvantages of cached mode, listed as below:
  - redundancy information and memory consumption: due to the fact that usually
    the application on top of DPDK will also store such information for
    management purpose.
  - moreover, flows may be not valid or used anymore after a device restarting
   Process. There might even be some conflict with the configuration.
And in the meanwhile, from the description and definition of 'RTE Ethernet
Device API', there is no need for flow rules to be retained during the
rte_eth_dev_stop()/rte_eth_dev_start() process. Caching the flow rules makes no
sense, and cached mode is almost useless.

So we will remove the flow rules cache and move to the non-cached mode. In the
device closing stage, all the software resources for flows created will be freed
and corresponding hardware resources will be released. Then the total cost of
the memory will be reduced and the behavior of mlx5 PMD will comply fully with
the ethdev API expectations.
After a device restarting, all the needed flow rules should be reinserted via
the create routine in the rte_flow lib.

                 reply	other threads:[~2019-12-11  7:53 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=VI1PR05MB4192E3B248D056F7CF6B3333DD5A0@VI1PR05MB4192.eurprd05.prod.outlook.com \
    --to=bingz@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=matan@mellanox.com \
    --cc=orika@mellanox.com \
    --cc=shahafs@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).