The rte_security API which enables inline protocol/crypto feature
mandates that for every security session an rte_flow is created. This
would internally translate to a rule in the hardware which would do
packet classification.

In rte_securty, one SA would be one security session. And if an rte_flow
need to be created for every session, the number of SAs supported by an
inline implementation would be limited by the number of rte_flows the
PMD would be able to support.

If the fields SPI & IP addresses are allowed to be a range, then this
limitation can be overcome. Multiple flows will be able to use one rule
for SECURITY processing. In this case, the security session provided as
conf would be NULL.

Application should do an rte_flow_validate() to make sure the flow is
supported on the PMD.

Signed-off-by: Anoob Joseph <>
 lib/librte_ethdev/rte_flow.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
index f3a8fb1..4977d3c 100644
--- a/lib/librte_ethdev/rte_flow.h
+++ b/lib/librte_ethdev/rte_flow.h
@@ -1879,6 +1879,12 @@ struct rte_flow_action_meter {
  * direction.
  * Multiple flows can be configured to use the same security session.
+ *
+ * The NULL value is allowed for security session. If security session is NULL,
+ * then SPI field in ESP flow item and IP addresses in flow items 'IPv4' and
+ * 'IPv6' will be allowed to be a range. The rule thus created can enable
+ * SECURITY processing on multiple flows.
+ *
 struct rte_flow_action_security {
        void *security_session; /**< Pointer to security session structure. */

Reply via email to