From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Gregory Etelson <getelson@nvidia.com>, dev@dpdk.org
Cc: mkashani@nvidia.com, Ori Kam <orika@nvidia.com>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>,
Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [PATCH] ethdev: add template table resize API
Date: Mon, 29 Jan 2024 14:24:30 +0000 [thread overview]
Message-ID: <a6a1ce2f-ed6f-4cbf-8d96-3d5bed8773b5@amd.com> (raw)
In-Reply-To: <20231217093205.321082-1-getelson@nvidia.com>
On 12/17/2023 9:32 AM, Gregory Etelson wrote:
> Template table creation API sets table flows capacity.
> If application needs more flows then the table was designed for,
> the following procedures must be completed:
> 1. Create a new template table with larger flows capacity.
> 2. Re-create existing flows in the new table and delete flows from
> the original table.
> 3. Destroy original table.
>
> Application cannot always execute that procedure:
> * Port may not have sufficient resources to allocate a new table
> while maintaining original table.
> * Application may not have existing flows "recipes" to re-create
> flows in a new table.
>
> The patch defines a new API that allows application to resize
> existing template table:
>
> * Resizable template table must be created with the
> RTE_FLOW_TABLE_SPECIALIZE_RESIZABLE_TABLE bit set.
>
> * Application resizes existing table with the
> `rte_flow_template_table_resize()` function call.
> The table resize procedure updates the table maximal flow number
> only. Other table attributes are not affected by the table resize.
> ** The table resize procedure must not interrupt
> existing table flows operations in hardware.
> ** The table resize procedure must not alter flow handlers held by
> application.
>
> * After `rte_flow_template_table_resize()` returned, application must
> update all existing table flow rules by calling
> `rte_flow_async_update_resized()`.
> The table resize procedure does not change application flow handler.
> However, flow object can reference internal PMD resources that are
> obsolete after table resize.
> `rte_flow_async_update_resized()` moves internal flow references
> to the updated table resources.
> The flow update must not interrupt hardware flow operations.
>
> * When all table flow were updated, application must call
> `rte_flow_template_table_resize_complete()`.
> The function releases PMD resources related to the original
> table.
> Application can start new table resize after
> `rte_flow_template_table_resize_complete()` returned.
>
Hi Gregory, Ori,
Why we need three separate APIs,
rte_flow_template_table_resize
rte_flow_async_update_resized
rte_flow_template_table_resize_complete
Why not 'rte_flow_template_table_resize()' update existing flows and
release resources related to the original tables automatically?
next prev parent reply other threads:[~2024-01-29 14:24 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-17 9:32 Gregory Etelson
2024-01-29 14:24 ` Ferruh Yigit [this message]
2024-01-29 15:08 ` Etelson, Gregory
2024-01-30 8:58 ` Ferruh Yigit
2024-01-30 12:46 ` Etelson, Gregory
2024-01-30 14:34 ` Ferruh Yigit
2024-01-30 18:15 ` Etelson, Gregory
2024-02-08 12:46 ` Ferruh Yigit
2024-02-09 5:55 ` Etelson, Gregory
2024-01-30 14:56 ` Ferruh Yigit
2024-01-30 18:49 ` Etelson, Gregory
2024-01-31 9:59 ` [PATCH v2] " Gregory Etelson
2024-02-06 22:31 ` Thomas Monjalon
2024-02-07 7:09 ` Etelson, Gregory
2024-02-07 7:03 ` [PATCH v3] " Gregory Etelson
2024-02-07 17:36 ` [PATCH v4] " Gregory Etelson
2024-02-11 9:30 ` [PATCH v5] " Gregory Etelson
2024-02-12 14:02 ` Thomas Monjalon
2024-02-12 14:48 ` Etelson, Gregory
2024-02-12 14:14 ` Ferruh Yigit
2024-02-12 15:01 ` Etelson, Gregory
2024-02-12 15:07 ` Ferruh Yigit
2024-02-12 18:12 ` [PATCH v6] " Gregory Etelson
2024-02-12 20:30 ` Ferruh Yigit
2024-02-13 11:51 ` Thomas Monjalon
2024-02-14 14:32 ` [PATCH v7] " Gregory Etelson
2024-02-14 14:42 ` Thomas Monjalon
2024-02-14 15:56 ` Ferruh Yigit
2024-02-14 17:07 ` Etelson, Gregory
2024-02-14 21:59 ` Ferruh Yigit
2024-02-15 5:41 ` Etelson, Gregory
2024-02-15 6:13 ` [PATCH v8] " Gregory Etelson
2024-02-15 13:13 ` Ferruh Yigit
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=a6a1ce2f-ed6f-4cbf-8d96-3d5bed8773b5@amd.com \
--to=ferruh.yigit@amd.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=getelson@nvidia.com \
--cc=mkashani@nvidia.com \
--cc=orika@nvidia.com \
--cc=thomas@monjalon.net \
--cc=yuying.zhang@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).