The transfer domain rule is able to match traffic wire/vf
origin and it means two directions' underlayer resource.
In customer deployments, they usually match only one direction
traffic in single flow table: either from wire or from vf.
Introduce one new member transfer_mode into rte_flow_template_table_attr
to indicate the flow table direction property: from wire, from vf
or bi-direction(default).
It helps to save underlayer memory also on insertion rate, and this
new field doesn't expose any matching criteira.
By default, the transfer domain is to match bi-direction traffic, and
no behavior changed.
1. Match wire origin only
flow template_table 0 create group 0 priority 0 transfer wire_orig...
2. Match vf origin only
flow template_table 0 create group 0 priority 0 transfer vf_orig...
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
v2: Move the new field to template table attribute.
---
app/test-pmd/cmdline_flow.c | 26 +++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 7 ++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 ++-
lib/ethdev/rte_flow.h | 9 ++++++-
4 files changed, 43 insertions(+), 2 deletions(-)
@@ -178,6 +178,8 @@ enum index {
TABLE_INGRESS,
TABLE_EGRESS,
TABLE_TRANSFER,
+ TABLE_TRANSFER_WIRE_ORIG,
+ TABLE_TRANSFER_VF_ORIG,
TABLE_RULES_NUMBER,
TABLE_PATTERN_TEMPLATE,
TABLE_ACTIONS_TEMPLATE,
@@ -1142,6 +1144,8 @@ static const enum index next_table_attr[] = {
TABLE_INGRESS,
TABLE_EGRESS,
TABLE_TRANSFER,
+ TABLE_TRANSFER_WIRE_ORIG,
+ TABLE_TRANSFER_VF_ORIG,
TABLE_RULES_NUMBER,
TABLE_PATTERN_TEMPLATE,
TABLE_ACTIONS_TEMPLATE,
@@ -2882,6 +2886,18 @@ static const struct token token_list[] = {
.next = NEXT(next_table_attr),
.call = parse_table,
},
+ [TABLE_TRANSFER_WIRE_ORIG] = {
+ .name = "wire_orig",
+ .help = "affect rule direction to transfer",
+ .next = NEXT(next_table_attr),
+ .call = parse_table,
+ },
+ [TABLE_TRANSFER_VF_ORIG] = {
+ .name = "vf_orig",
+ .help = "affect rule direction to transfer",
+ .next = NEXT(next_table_attr),
+ .call = parse_table,
+ },
[TABLE_RULES_NUMBER] = {
.name = "rules_number",
.help = "number of rules in table",
@@ -8895,6 +8911,16 @@ parse_table(struct context *ctx, const struct token *token,
case TABLE_TRANSFER:
out->args.table.attr.flow_attr.transfer = 1;
return len;
+ case TABLE_TRANSFER_WIRE_ORIG:
+ if (!out->args.table.attr.flow_attr.transfer)
+ return -1;
+ out->args.table.attr.transfer_mode = 1;
+ return len;
+ case TABLE_TRANSFER_VF_ORIG:
+ if (!out->args.table.attr.flow_attr.transfer)
+ return -1;
+ out->args.table.attr.transfer_mode = 2;
+ return len;
default:
return -1;
}
@@ -3748,6 +3748,13 @@ the maximum number of flow rules is defined at table creation time.
Any flow rule creation beyond the maximum table size is rejected.
Application may create another table to accommodate more rules in this case.
+Attribute: transfer_mode
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+This is an optional table attribute and meaningless if `Attribute: Transfer`
+is not specified. It doesn't expose any matching criteria but just as a hint
+to indicate PMD where to bound the rules.
+
.. code-block:: c
struct rte_flow_template_table *
@@ -3125,7 +3125,8 @@ It is bound to ``rte_flow_template_table_create()``::
flow template_table {port_id} create
[table_id {id}] [group {group_id}]
- [priority {level}] [ingress] [egress] [transfer]
+ [priority {level}] [ingress] [egress]
+ [transfer [vf_orig] [wire_orig]]
rules_number {number}
pattern_template {pattern_template_id}
actions_template {actions_template_id}
@@ -130,7 +130,7 @@ struct rte_flow_attr {
* through a suitable port. @see rte_flow_pick_transfer_proxy().
*/
uint32_t transfer:1;
- uint32_t reserved:29; /**< Reserved, must be zero. */
+ uint32_t reserved:27; /**< Reserved, must be zero. */
};
/**
@@ -5233,6 +5233,13 @@ struct rte_flow_template_table_attr {
* Maximum number of flow rules that this table holds.
*/
uint32_t nb_flows;
+ /**
+ * 0 means bidirection,
+ * 0x1 origin uplink,
+ * 0x2 origin vport,
+ * N/A both set.
+ */
+ uint32_t transfer_mode:2;
};
/**