Hi,
15/04/2025 20:21, Dean Marx:
> The flow API allows for an extremely broad set of rules to be created.
> My understanding from my first pass at writing the test suite is that
> there is a small subset of those rules that are “core functionality”
> that the flow API aims to support, and there are also rules which
> technically can be created, but may not be supported by the main PMDs
> and/or may not be useful rules that people want to see tested.
>
> For instance, I am pretty confident that a rule like the one below is
> one which the community will care about, and which PMDs will support:
>
> flow create 0 ingress pattern eth / ipv4 src is 192.168.0.1 / end
> actions drop / end
>
> But I do not know what is the full set of rules that I should be
> validating from a DTS testsuite. Is it possible for you (or anyone
> else on this mailing list) to provide some feedback on what rules are
> most important and I should include in my test suite? If I can get
> that feedback, I will draft a test plan and share it back on this
> thread for community approval before I write up and submit the DTS
> patch.
Ultimately it would be nice to test all flow items and actions.
As this is the first step of this long journey,
I agree we should focus on the minimum.
We can focus on the simple synchronous API for now,
and leave the template asynchronous API for a next step.
Let's talk about basic items and actions to test
simple forwarding rules.
Items are describing protocols.
The most common ones are:
- RTE_FLOW_ITEM_TYPE_ETH
- RTE_FLOW_ITEM_TYPE_IPV4 / RTE_FLOW_ITEM_TYPE_IPV6
- RTE_FLOW_ITEM_TYPE_UDP
- RTE_FLOW_ITEM_TYPE_TCP
- RTE_FLOW_ITEM_TYPE_VLAN
Some header field values may be specified as well in the rule.
You probably want to test matching each field of these items,
except checksums, lengths, offsets.
The traffic direction can be specified with:
- rte_flow_attr.ingress
- rte_flow_attr.egress
The most basic actions are to specify where to forward a flow:
- RTE_FLOW_ACTION_TYPE_QUEUE
- RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
- RTE_FLOW_ACTION_TYPE_RSS
- RTE_FLOW_ACTION_TYPE_DROP
Next we want to create flow rules in groups:
- rte_flow_attr.group
- rte_flow_attr.priority
and connect groups with
- RTE_FLOW_ACTION_TYPE_JUMP
The most versatile action is to modify packets (like TTL or src/dest) with
- RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
I believe you should play with that first.
Any other opinions?
