[PATCH v1 6/6] net/ice: centralize flow rule memory management

Burakov, Anatoly anatoly.burakov at intel.com
Wed Oct 21 12:07:56 CEST 2026


On 10/21/2026 11:59 AM, Bruce Richardson wrote:
> On Tue, Oct 20, 2026 at 01:11:09PM +0100, Anatoly Burakov wrote:
>> Flow engines manage rule memory independently, with parsers returning
>> either temporary metadata or shared scratch storage. This spreads
>> ownership and cleanup across parsing, creation, destruction and
>> uninitialization across the flow infrastructure, which is difficult to
>> verify, reason about, and may have hidden bugs.
>>
>> Make parsers allocate the final rule and transfer ownership to the
>> generic flow layer on success. Free rules centrally after validation,
>> failed creation, successful destruction and uninitialization, retaining
>> them when destruction fails. Parsers clean up their own allocations on
>> failure.
>>
>> Some engines, in addition to the rule itself, will also allocate additional
>> data for the flow (e.g. RAW pattern buffer in FDIR engine). We can make the
>> flow memory management centralized in generic flow, but this additional
>> data is engine-specific, so use the `free` callbacks to release only said
>> additional flow data. Remove the RSS and ACL callbacks, the FDIR and ACL
>> scratch storage, and the redundant allocations and copies during rule
>> creation, and use stack storage where appropriate.
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
> Acked-by: Bruce Richardson <bruce.richardson at intel.com>
> 
> After this cleanup, it looks like the flow parameter to each engine can be
> removed completely, since all four engines mark it as __rte_unused now.
> 
Yes, true. In ice, flows are basically two (or more) allocations - the 
flow header itself, and the actual rule it encodes (with whatever nested 
allocations the rule has - switch and FDIR RAW do that), but all of the 
latter happens inside the `flow->rule` pointer, so the `flow` itself is 
not needed. Arguably, `meta` also needs renaming into `rule`, because 
that's what it does now: it is meant to be a pointer to `flow->rule`.
-- 
Thanks,
Anatoly


More information about the dev mailing list