[PATCH v3 09/19] net/ixgbe: reimplement security parser
Burakov, Anatoly
anatoly.burakov at intel.com
Mon Oct 5 14:16:12 CEST 2026
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 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).
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
More information about the dev
mailing list