doc: flow rule removal on port stop
PATCH 1/1 doc: flow rule removal on port stop
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:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
--- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
doc/guides/prog_guide/rte_flow.rst +2 -3
@@ -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:
Signature · 1 line
2.25.1
PATCH 1/1 doc: flow rule removal on port stop
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:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
--- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
doc/guides/prog_guide/rte_flow.rst +2 -3
@@ -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:
Signature · 1 line
2.25.1
Quoted 49 lines · Gregory Etelson
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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 protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)doc/guides/prog_guide/rte_flow.rst +0
-0@@ -3055,10 +3055,9 @@ Caveats temporarily replacing the burst function pointers), an appropriate error code must be returned (``EBUSY``).
doc/guides/prog_guide/rte_flow.rst Caveats · line 3063
Quoted 10 lines
doc/guides/prog_guide/rte_flow.rst +2
-3-- 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)
Hello Andrew,
Quoted 63 lines · Gregory Etelson
Quoted 47 lines
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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 protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)doc/guides/prog_guide/rte_flow.rst +0
-0doc/guides/prog_guide/rte_flow.rst Caveats · line 3055
Quoted 1 line
doc/guides/prog_guide/rte_flow.rst +0
-0@@ -3055,10 +3055,9 @@ Caveats temporarily replacing the burst function pointers), an appropriateerror
doc/guides/prog_guide/rte_flow.rst Caveats
Quoted 12 lines
doc/guides/prog_guide/rte_flow.rst +1
-1code 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 performingother
- actions which may affect them. They can only be destroyed explicitly bydoc/guides/prog_guide/rte_flow.rst +1
-1- applications. + actions which may affect them. For devices exposing multiple ports sharing global settings affectedby flow
Quoted 8 lines
Quoted 2 lines
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.
Quoted 68 lines · Gregory Etelson
Hello Andrew,
Quoted 66 lines · Gregory Etelson
Quoted 47 lines
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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 protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)doc/guides/prog_guide/rte_flow.rst +0
-0doc/guides/prog_guide/rte_flow.rst Caveats · line 3055
Quoted 1 line
doc/guides/prog_guide/rte_flow.rst +0
-0@@ -3055,10 +3055,9 @@ Caveats temporarily replacing the burst function pointers), an appropriateerror
doc/guides/prog_guide/rte_flow.rst Caveats
Quoted 12 lines
doc/guides/prog_guide/rte_flow.rst +1
-1code 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 performingother
- actions which may affect them. They can only be destroyed explicitly bydoc/guides/prog_guide/rte_flow.rst +1
-1- applications. + actions which may affect them. For devices exposing multiple ports sharing global settings affectedby flow
Quoted 2 lines
rules:
Quoted 7 lines
Quoted 5 lines
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.
Quoted 76 lines
Quoted 76 lines
Quoted 75 lines · Gregory Etelson
Quoted 48 lines
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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 protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)doc/guides/prog_guide/rte_flow.rst +0
-0@@ -3055,10 +3055,9 @@ Caveats temporarily replacing the burst function pointers), anQuoted 1 line
appropriate
error
Quoted 14 lines
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 bydoc/guides/prog_guide/rte_flow.rst +1
-1- applications. + actions which may affect them. For devices exposing multiple ports sharing global settingsQuoted 1 line
affected
by flow
Quoted 2 lines
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)
Quoted 4 lines
Quoted 1 line
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.
PATCH v2 1/1 doc: flow rule removal on port stop
In reply to Gregory EtelsonThere 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:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
--- doc/guides/prog_guide/rte_flow.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
doc/guides/prog_guide/rte_flow.rst +6 -4
@@ -3229,10 +3229,12 @@ Caveats temporarily replacing the burst function pointers), an appropriate error code must be returned (``EBUSY``). -- PMDs, not applications, 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. +- Applications, not PMDs, are responsible for maintaining flow rules + configuration when closing, stopping or restarting a port or performing other + actions which may affect them. + Applications must assume that after port close, stop or restart all flows + related to that port are not valid, hardware rules are destroyed and relevant + PMD resources are released. For devices exposing multiple ports sharing global settings affected by flow rules:
Signature · 1 line
2.29.2
Andrew, any comment on this v2?
(disclosure: I did not read it)
18/11/2020 17:15, Gregory Etelson:
Quoted 63 lines
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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 protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)doc/guides/prog_guide/rte_flow.rst +6
-4@@ -3229,10 +3229,12 @@ Caveats temporarily replacing the burst function pointers), an appropriate error code must be returned (``EBUSY``). -- PMDs, not applications, 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. +- Applications, not PMDs, are responsible for maintaining flow rules + configuration when closing, stopping or restarting a port or performing other + actions which may affect them. + Applications must assume that after port close, stop or restart all flows + related to that port are not valid, hardware rules are destroyed and relevant + PMD resources are released. For devices exposing multiple ports sharing global settings affected by flow rules:
There is also a testpmd patch pending about this behaviour:
https://patches.dpdk.org/patch/75353/
22/11/2020 17:55, Thomas Monjalon:
Quoted 67 lines
Andrew, any comment on this v2?
(disclosure: I did not read it)18/11/2020 17:15, Gregory Etelson:
Quoted 62 lines
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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 protected]>Acked-by Ori Kam <[email protected]>--- doc/guides/prog_guide/rte_flow.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)doc/guides/prog_guide/rte_flow.rst +6
-4@@ -3229,10 +3229,12 @@ Caveats temporarily replacing the burst function pointers), an appropriate error code must be returned (``EBUSY``). -- PMDs, not applications, 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. +- Applications, not PMDs, are responsible for maintaining flow rules + configuration when closing, stopping or restarting a port or performing other + actions which may affect them. + Applications must assume that after port close, stop or restart all flows + related to that port are not valid, hardware rules are destroyed and relevant + PMD resources are released. For devices exposing multiple ports sharing global settings affected by flow rules:
Quoted 36 lines · Gregory Etelson
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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.
Quoted 2 lines
Signed-off-by Gregory Etelson <[email protected]>Acked-by Ori Kam <[email protected]>
Quoted 28 lines
--- doc/guides/prog_guide/rte_flow.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)doc/guides/prog_guide/rte_flow.rst +6
-5@@ -3229,10 +3229,12 @@ Caveats temporarily replacing the burst function pointers), an appropriate error code must be returned (``EBUSY``). -- PMDs, not applications, 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. +- Applications, not PMDs, are responsible for maintaining flow rules + configuration when closing, stopping or restarting a port or performing other + actions which may affect them. + Applications must assume that after port close, stop or restart all flows + related to that port are not valid, hardware rules are destroyed and relevant + PMD resources are released. For devices exposing multiple ports sharing global settings affected by flow rules: --2.29.2
24/11/2020 15:41, Ajit Khaparde:
Quoted 37 lines · Gregory Etelson
Quoted 36 lines
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.hdeclares that flow rules will not be stored in PMD after port stop:Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
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 endPMD 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.
Quoted 15 lines
Quoted 2 lines
Signed-off-by Gregory Etelson <[email protected]>Acked-by Ori Kam <[email protected]>Acked-by Ajit Khaparde <[email protected]>Quoted 11 lines
---
-- PMDs, not applications, are responsible for maintaining flow rulesdoc/guides/prog_guide/rte_flow.rst +6
-3- configuration when stopping and restarting a port or performing other - actions which may affect them. They can only be destroyed explicitly by - applications. +- Applications, not PMDs, are responsible for maintaining flow rules + configuration when closing, stopping or restarting a port or performing other + actions which may affect them. + Applications must assume that after port close, stop or restart all flows + related to that port are not valid, hardware rules are destroyed and relevant + PMD resources are released.
In short summary, this rte_flow doc change has 3 reasons:
- consistency with ethdev API doc
- avoid unsolvable automatic flow update after re-configuration
- reduce memory consumption for flow rules
Andrew was asking, in previous version, how to manage reset for error recovery. As it has been discussed in other threads, an error recovery should be notified to the application.
We already have RTE_ETH_EVENT_INTR_RESET for VF in case of PF reset, and a more general recovery notification mechanism is being discussed:
https://patches.dpdk.org/patch/80094/
Then it will be possible to notify the application that the flow rules must be restored (among other recovery measures).
For the case of port stop/close, doc update applied, thanks.