[PATCH v3 09/19] net/ixgbe: reimplement security parser
Medvedkin, Vladimir
vladimir.medvedkin at intel.com
Sat Sep 19 18:11:11 CEST 2026
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<anatoly.burakov at intel.com>
> ---
<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
More information about the dev
mailing list