On 9/16/2026 1:18 PM, Anatoly Burakov wrote:
Use the new flow graph API and common flow engine infrastructure to
implement flow parser for security filter. As a result, flow item checks
have become more stringent:
- Mask is now explicitly validated to not have unsupported items in it,
when previously they were ignored
- Mask is also validated to mask src/dst addresses, as otherwise it is
inconsistent with rte_flow API
Previously, security parser was a special case, now it is a first class
citizen. All decryption SA tracking has been moved into the engine, as the
engine is now the authoritative source of new Rx flows and the state of
the Rx SA table (the Tx SA table is still up to IPsec code to manage).
Because IPsec code does not manage the Rx SA table now, a synchronization
mechanism is needed to prevent IPsec code from deallocating a security
session when it is still referenced by security flows, so the security
session is now atomically refcounted. For Tx, the refcount is effectively
a noop, whereas for Rx it is now managed by rte_flow security engine.
Signed-off-by: Anatoly Burakov<[email protected]>
---
<snip>
+/**
+ * Ntuple security filter graph implementation
+ * Pattern: START -> IPV4 | IPV6 -> END
Previously, pattern support was not as restrictive. At least, we could
have an Ethernet header in the pattern. With the current implementation,
ipsec-secgw could fail, since it can create an ETH/IPV4/ESP/END pattern
(please refer to flow_init_single() in ipsec-secgw).
+ */
+
<snip>
--
Regards,
Vladimir