DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH v1 5/6] net/ice: use caller-owned pattern match storage
Date: Wed, 21 Oct 2026 11:55:34 +0200	[thread overview]
Message-ID: <3c6bee19-388a-4c8f-8918-40b8afed4e5e@intel.com> (raw)
In-Reply-To: <atiFJHpIIhwH_AHh@bricha3-mobl1.ger.corp.intel.com>

On 10/21/2026 11:25 AM, Bruce Richardson wrote:
> On Tue, Oct 20, 2026 at 01:11:08PM +0100, Anatoly Burakov wrote:
>> Pattern lookup allocates a match item just to copy an entry from the
>> engine's supported-pattern table. Each engine must then free this
>> temporary object after parsing.
>>
>> Make `ice_search_pattern_match_item()` fill caller-provided storage
>> and return a status code. Use stack-local match items in all four
>> engines, removing the allocation and corresponding cleanup paths.
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> I'm sure there are still plenty more cleanups that can be done converting
> dynamic to stack storage. Even a quick review of this change shows that the
> "rss_meta_ptr" value in ice_hash_parse_pattern_action can be just put on
> stack to simplify the code.

If you mean allocate the meta on the stack, that particular fix wouldn't 
pan out because of the way engines manage memory (basically, 
rss_meta_ptr is the one that has to persist, so it has to be allocated 
on the heap). If you mean allocate the meta on the stack *in the 
caller*, that would work but require some re-plumbing because we'd need 
a union of all possible metadatas to pass into the parse function. So, 
doable, but a bit more work than just putting things on the stack.

This suggestion is also nullified by patch 6, because it makes it so 
that the final flow object is allocated by the parse function, so 
there's no more "metadata" passing between pattern matcher and the 
engine - the heap-allocated object is the one we store in the flow list.

However, you're right that there's plenty of things we could've done 
differently when it comes to memory management, and future work porting 
ice to flow_engine framework will fix all of these issues in flow our 
API (and will get rid of the nested allocations that are still kept in 
patch 6).

>> ---
>>   drivers/net/intel/ice/ice_acl_filter.c    | 22 ++++++++------------
>>   drivers/net/intel/ice/ice_fdir_filter.c   | 18 ++++++++--------
>>   drivers/net/intel/ice/ice_generic_flow.c  | 25 +++++------------------
>>   drivers/net/intel/ice/ice_generic_flow.h  |  3 ++-
>>   drivers/net/intel/ice/ice_hash.c          | 13 +++++-------
>>   drivers/net/intel/ice/ice_switch_filter.c | 14 +++++--------
>>   6 files changed, 34 insertions(+), 61 deletions(-)
>>


-- 
Thanks,
Anatoly

  reply	other threads:[~2026-10-21  9:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 12:11 [PATCH v1 0/6] Centralize flow memory management in ICE Anatoly Burakov
2026-10-20 12:11 ` [PATCH v1 1/6] net/ice: release ACL slot on entry creation failure Anatoly Burakov
2026-10-21  9:17   ` Bruce Richardson
2026-10-20 12:11 ` [PATCH v1 2/6] net/ice: fix inconsistent state on FDIR failure Anatoly Burakov
2026-10-21  9:17   ` Bruce Richardson
2026-10-20 12:11 ` [PATCH v1 3/6] net/ice: standardize VOID handling in flow parsers Anatoly Burakov
2026-10-21  9:18   ` Bruce Richardson
2026-10-20 12:11 ` [PATCH v1 4/6] net/ice: remove temporary flow pattern buffer Anatoly Burakov
2026-10-21  9:19   ` Bruce Richardson
2026-10-20 12:11 ` [PATCH v1 5/6] net/ice: use caller-owned pattern match storage Anatoly Burakov
2026-10-21  9:25   ` Bruce Richardson
2026-10-21  9:55     ` Burakov, Anatoly [this message]
2026-10-20 12:11 ` [PATCH v1 6/6] net/ice: centralize flow rule memory management Anatoly Burakov
2026-10-21  9:59   ` Bruce Richardson
2026-10-21 10:07     ` Burakov, Anatoly
2026-10-21 10:02 ` [PATCH v1 0/6] Centralize flow memory management in ICE Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3c6bee19-388a-4c8f-8918-40b8afed4e5e@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox