Flow API Test Suite Inquiry

Flow API Test Suite Inquiry

[Dean Marx]

Hello Ori,


I work at the UNH-IOL DPDK Community Lab, and I am writing an rte_flow
test suite to add to the DPDK Test Suite.


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.


Thanks for your time,

Dean Marx

Re: Flow API Test Suite Inquiry

[Thomas Monjalon]

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?