From: Gregory Etelson <email@example.com> To: Andrew Rybchenko <firstname.lastname@example.org> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Matan Azrad <email@example.com>, Ori Kam <firstname.lastname@example.org>, NBU-Contact-Thomas Monjalon <email@example.com> Subject: Re: [dpdk-dev] [PATCH] doc: flow rule removal on port stop Date: Wed, 18 Nov 2020 09:06:23 +0000 Message-ID: <MN2PR12MB4639F44503090F49B7E57449A5E10@MN2PR12MB4639.namprd12.prod.outlook.com> (raw) In-Reply-To: <firstname.lastname@example.org> > >> On 11/17/20 10:18 PM, Gregory Etelson wrote: > >>> There is a discrepancy between RTE ETHDEV API and flow rules guide > >>> regarding flow rules maintenance after port stop. RTE ETHDEV API in > >>> librte_ethdev.h declares that flow rules will not be stored in PMD > >>> after port stop: > >>> >>>>> Quite start > >>> Please note that some configuration is not stored between calls to > >>> rte_eth_dev_stop()/rte_eth_dev_start(). The following configuration > >>> will be retained: > >>> > >>> - MTU > >>> - flow control settings > >>> - receive mode configuration (promiscuous mode, all-multicast mode, > >>> hardware checksum mode, RSS/VMDQ settings etc.) > >>> - VLAN filtering configuration > >>> - default MAC address > >>> - MAC addresses supplied to MAC address array > >>> - flow director filtering mode (but not filtering rules) > >>> - NIC queue statistics mappings > >>> <<<< Quote end > >>> > >>> PMD cannot always correctly restore flow rules after port stop / > >>> port start because application may alter port configuration after > >>> port stop without PMD knowledge about undergoing changes. Consider > >>> the following scenario: > >>> application configures 2 queues 0 and 1 and creates a flow rule with > >>> 'queue index 1' action. After that application stops the port and > >>> removes queue 1. > >>> Although PMD can implement flow rule shadow copy to be used for > >>> restore after port start, attempt to restore flow rule from shadow > >>> will fail in example above and PMD could not notify application > >>> about that failure. As the result, flow rules map in HW will differ > >>> from what application expects. In addition, flow rules shadow copy > >>> used for port start restore consumes considerable amount of system > >>> memory, especially in systems with millions of flow rules. > >>> > >>> Signed-off-by: Gregory Etelson <email@example.com> > >>> Acked-by: Ori Kam <firstname.lastname@example.org> > >>> --- > >>> doc/guides/prog_guide/rte_flow.rst | 5 ++--- > >>> 1 file changed, 2 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/doc/guides/prog_guide/rte_flow.rst > >>> b/doc/guides/prog_guide/rte_flow.rst > >>> index 944e8242d6..dfe5a40f8e 100644 > >>> --- a/doc/guides/prog_guide/rte_flow.rst > >>> +++ b/doc/guides/prog_guide/rte_flow.rst > >>> @@ -3055,10 +3055,9 @@ Caveats > >>> temporarily replacing the burst function pointers), an > >>> appropriate > >> error > >>> code must be returned (``EBUSY``). > >>> > >>> -- PMDs, not applications, are responsible for maintaining flow > >>> rules > >>> +- Applications, not PMDs, are responsible for maintaining flow > >>> +rules > >>> configuration when stopping and restarting a port or performing > >>> other > >>> - actions which may affect them. They can only be destroyed > >>> explicitly by > >>> - applications. > >>> + actions which may affect them. > >>> > >>> For devices exposing multiple ports sharing global settings > >>> affected > >> by flow > >>> rules: > >>> > >> > >> Re-reading it, it still looks vague. What happens on: > >> - port stop without removal of flow rule before > >> - port close without removal of flow rules before > >> - port reset (which could be stop/start, e.g. to recover from error > >> condition) > > > > PMD should remove all flows related to hardware resource that was > invalidated. > > Stop? Close? I agree and documentation should say so in a bit clear way. I'll post updated document patch.
next prev parent reply other threads:[~2020-11-18 9:06 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-16 11:18 Gregory Etelson 2020-11-17 19:18 ` Gregory Etelson 2020-11-17 19:56 ` Andrew Rybchenko 2020-11-18 8:59 ` Gregory Etelson 2020-11-18 9:04 ` Andrew Rybchenko 2020-11-18 9:06 ` Gregory Etelson [this message] 2020-11-18 16:15 ` [dpdk-dev] [PATCH v2] " Gregory Etelson 2020-11-22 16:55 ` Thomas Monjalon 2020-11-24 11:04 ` Thomas Monjalon 2020-11-24 14:41 ` Ajit Khaparde 2020-11-25 23:33 ` Thomas Monjalon
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=MN2PR12MB4639F44503090F49B7E57449A5E10@MN2PR12MB4639.namprd12.prod.outlook.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
DPDK patches and discussions This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \ email@example.com public-inbox-index dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git