Re: [PATCH v3 09/19] net/ixgbe: reimplement security parser

["Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>]

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@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