DPDK patches and discussions
 help / color / mirror / Atom feed
* Re: [PATCH v2 02/10] ethdev: add flow item/action templates
@ 2022-01-19 15:16 Ivan Malov
  2022-01-25  4:04 ` Alexander Kozyrev
  0 siblings, 1 reply; 3+ messages in thread
From: Ivan Malov @ 2022-01-19 15:16 UTC (permalink / raw)
  To: dev

Hi,

> +Oftentimes in an application, many flow rules share a common structure
> +(the same pattern and/or action list) so they can be grouped and 
classified
> +together. This knowledge may be used as a source of optimization by a 
PMD/HW.
> +The flow rule creation is done by selecting a table, an item template
> +and an action template (which are bound to the table), and setting 
unique
> +values for the items and actions. This API is not thread-safe.

Consider:

+Typically, flow rules generated by a given application conform to a small
+group of "shapes". What defines a "shape" is a set of specific item masks
+and action types. This knowledge facilitates optimisations in PMDs / HW.
+
+With such "shapes" (templates) being grouped in tables, a flow rule can
+be created by selecting a template (pattern, action list) within a given
+table and filling out specific match / action properties.

> +     struct rte_flow_item_template *
> +     rte_flow_item_template_create(uint16_t port_id,
> +                             const struct rte_flow_item_template_attr 
*it_attr,
> +                             const struct rte_flow_item items[],
> +                             struct rte_flow_error *error);

I'm afraid "it_attr" is hardly readable. Also, the API name can
trick users into thinking that it's all about creating a single
item template rather than a flow pattern template.

Perhaps rename to "rte_flow_pattern_template_create()"?
Use "tmpl" instead of "template"? Or "shape" maybe?

For sure, "const struct rte_flow_item items[]" would look better
when renamed to "const struct rte_flow_item pattern[]".

The same goes for "rte_flow_action_template_create()" and "at_attr".

Perhaps, "rte_flow_action_list_shape_create()" then?

> +A table combines a number of item and action templates along with 
shared flow
> +rule attributes (group ID, priority and traffic direction). This way a 
PMD/HW

Please consider:

+A template table consists of multiple pattern templates and action list
+templates associated with a single set of rule attributes (group ID,
+priority, etc).

Perhaps rename "item_templates[]" and "action_templates[]"
to "pattern_templates[]" and "action_list_templates[]".
Maybe make use of the term "shape" here as well...

> +     /**
> +      * Relaxed matching policy, PMD may match only on items
> +      * with mask member set and skip matching on protocol
> +      * layers specified without any masks.
> +      * If not set, PMD will match on protocol layers
> +      * specified without any masks as well.
> +      * Packet data must be stacked in the same order as the
> +      * protocol layers to match inside packets,
> +      * starting from the lowest.
> +      */
> +     uint32_t relaxed_matching:1;

Consider rewording this to a bullet-formatted set of statements.
For brevity. For improved clarity.

> +      * Flow attributes that will be used in the table.

Perhaps: "Flow attributes to be used in each rule generated from this
table". Something like that.

> +                   struct rte_flow_item_template *item_templates[],
Perhaps, "const struct"? The name could be "pattern_templates".

> +                   uint8_t nb_item_templates,
Why not "unsigned int"? The name could be "nb_pattern_templates".

> +                   struct rte_flow_action_template *action_templates[],
> +                   uint8_t nb_action_templates,
Same questions here.

--
Ivan M.

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [dpdk-dev] [RFC 0/3] ethdev: datapath-focused flow rules management
@ 2021-10-06  4:48 Alexander Kozyrev
  2022-01-18 15:30 ` [PATCH v2 00/10] " Alexander Kozyrev
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Kozyrev @ 2021-10-06  4:48 UTC (permalink / raw)
  To: dev
  Cc: thomas, orika, ivan.malov, andrew.rybchenko, ferruh.yigit,
	mohammad.abdul.awal, qi.z.zhang, jerinj, ajit.khaparde

The current flow rules insertion mechanism assumes applications
manage flow rules lifecycle in the control path. The flow rules
creation/destruction is performed synchronously and under a lock.
But for applications doing this job as part of the datapath, any
blocking operations are not desirable as they cause delay in the
packet processing.

These patches optimize a datapath-focused flow rules management
approach based on four main concepts:

1. Pre-configuration hints.
In order to reduce the overhead of the flow rules management, the
application may provide some hints at the initialization phase about
flow rules characteristics to be used. The configuration funtion
pre-allocates all the needed resources inside a PMD/HW beforehand and
these resources are used at a later stage without costly allocations.

2. Flow grouping using templates.
Unlike current stage where each flow rule is treated as independent entity,
new approach can leverage application knowledge about common patterns in
most of flows. Similar flows are grouped toghether using templates to enable
better resource management inside the PMD/HW.

3. Queue-based flow management.
Flow rules creation/destruction is done by using lockless flow queues.
The application configures number of queues during the initialization stage.
Then create/destroy operations are enqueued without any lock.

4. Asynchronous operations.
There is a way to spare the datapath from waiting for the flow rule
creation/destruction. Adopting an asynchronous queue-based approach,
the packet processing can continue with handling next packets while
inserting/deleting a flow rule inside the hardware. The application
is expected to poll for results later to see if the flow rule is
successfully inserted/deleted or not.

Example on how to use this approach. Init stage consists from the resources
preallocation, item and action templates definition and corresponding tables
create. All these steps should be done before a device is started:

rte_eth_dev_configure();
rte_flow_configure(port_id, number_of_flow_queues, max_num_of_counters);
rte_flow_item_template_create(port_id, items("eth/ipv4/udp"));
rte_flow_action_template_create(port_id, actions("counter/set_tp_src"));
rte_flow_table_create(port_id, item_template, action_template);
rte_eth_dev_start();

The packet processing can start once all the resources are preallocated.
Flow rules creation/destruction jobs are enqueued as a part of the packet
handling logic. These jobs are then flushed to the PMD/HW and their status
is beign rquested via the dequeue API as a method to ensure flow rules
are successfully created/destroyed.

rte_eth_rx_burst();
for (every received packet in the burts) {
  if (flow rule needs to be created) {
    rte_flow_q_flow_create(port_id, flow_queue_id, table_id,
        item_template_id, items("eth/ipv4 is 1.1.1.1/udp"),
         action_template_id, actions("counter/set_tp_src is 5555"));
  } else {flow rule needs tp be destroyed) {
    rte_flow_q_flow_destroy(port_id, flow_queue_id, flow_rule_id);
  }
  rte_flow_q_flush(port_id, flow_queue_id);
  rte_flow_q_dequeue(port_id, flow_queue_id, &result);
}

Signed-off-by: Alexander Kozyrev <akozyrev@nvidia.com>
Suggested-by: Ori Kam <orika@nvidia.com>

Alexander Kozyrev (3):
  ethdev: introduce flow pre-configuration hints
  ethdev: add flow item/action templates
  ethdev: add async queue-based flow rules operations

 lib/ethdev/rte_flow.h | 626 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 626 insertions(+)

-- 
2.18.2


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-01-25  4:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-19 15:16 [PATCH v2 02/10] ethdev: add flow item/action templates Ivan Malov
2022-01-25  4:04 ` Alexander Kozyrev
  -- strict thread matches above, loose matches on Subject: below --
2021-10-06  4:48 [dpdk-dev] [RFC 0/3] ethdev: datapath-focused flow rules management Alexander Kozyrev
2022-01-18 15:30 ` [PATCH v2 00/10] " Alexander Kozyrev
2022-01-18 15:30   ` [PATCH v2 02/10] ethdev: add flow item/action templates Alexander Kozyrev

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).