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

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 9/19/2026 6:11 PM, Medvedkin, Vladimir wrote:
> 
> 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).

Previous code was not "not as restrictive", it just ignored everything 
before and after IPv4/IPv6 items. So, I'll add ETH in the beginning, and 
ESP/UDP after.

>> + */
>> +
> <snip>
> 


-- 
Thanks,
Anatoly