Range Matching
The range matching is supported using the template API. When creating a pattern template, the common bits of “mask” and “last” in the "struct rte_flow_item" are used to specify the fields that will be used in range matching. When inserting a rule with such pattern template, the “spec” in "struct rte_flow_item" is used to set the lower boundary and “last” is used as the upper boundary of a range. More than one fields of range matching can be supported in a single pattern template, and the bits only present in the “mask” are still treated as exact matching.
The supported items are IPv4 packet length, IPv4 destination address, IPv4 source address, IPv4 version and header length, IPv4 time to live, IPv6 hop limit, IPv6 payload length, UDP/TCP source port, UDP/TCP destination port, TCP flags, tag, and metadata.
With the IP length range matching, the user can redirect the packets with length > X to the slow path and handled in the software. In the meanwhile, other packets can be fully offloaded without any software participation.
For example, in a virtual environment in which network application vendors does not have full control on the network configuration, tenants can decide on MTU size and the network application should accommodate to it. Offloaded encapsulation actions are adding the tunnel header to a packet. To avoid a situation in which a packet size exceeds the MTU size, after its encapsulation (and later on dropped), the DPDK application can set a rule to check for the IP length, ensuring that it does not exceed a specified length. If it does, it can be redirected to slow path (DPDK application) for proper handling (e.g. split to multiple packets), otherwise, it can be treated in the hardware.
Currently, the complex actions cannot be supported with range matching, the terminate actions can be supported.
QUEUE, RSS, PORT_ID, REPRESENTED_PORT, JUMP, DROP
Once an error is observed with complaining the complex action template, it is recommended to handle the actions in the following rules.
To create the pattern template with IPv4 length range matching specified
flow pattern_template
0
create ingress relaxed no pattern_template_id1
template eth / ipv4 length mask0xffff
length last0xffff
/ endTo create the action template with count and jump actions
flow actions_template
0
create ingress actions_template_id1
template count / jump / end mask count / jump / endTo create the template table
flow template_table
0
create group1
priority0
ingress table_id0x11
pattern_template1
actions_template1
rules_number128
To insert a rule to match the length between 70 to 500 bytes
flow queue
0
create2
template_table0x11
pattern_template0
actions_template0
postpone no pattern eth / ipv4 length spec70
length last500
/ end actions count / jump group2
/ end flow pull0
queue2
…To insert another rule to match the length between 1500 to 4000 bytes
flow queue
0
create2
template_table0x11
pattern_template0
actions_template0
postpone no pattern eth / ipv4 length spec1500
length last4000
/ end actions count / jump group3
/ end flow pull0
queue2
…
Refer to the “Template API” section for the usage of the functions and steps.
struct rte_flow_item_ipv4 pt_ip = {
.hdr.total_length = 0xffff
,
};
struct rte_flow_item patterns[] = {
{
.type = RTE_FLOW_ITEM_TYPE_ETH,
},
{
.type = RTE_FLOW_ITEM_TYPE_IPV4,
.mask = &pt_ip,
.last = &pt_ip,
},
{
.type = RTE_FLOW_ITEM_TYPE_END,
},
};
struct rte_flow_item_ipv4 len_start = {
.hdr.total_length = RTE_BE16(70
),
};
struct rte_flow_item_ipv4 len_end = {
.hdr.total_length = RTE_BE16(500
),
};
struct rte_flow_item rule_items[] = {
{
.type = RTE_FLOW_ITEM_TYPE_ETH,
},
{
.type = RTE_FLOW_ITEM_TYPE_IPV4,
.mask = &len_start,
.last = &len_end,
},
{
.type = RTE_FLOW_ITEM_TYPE_END,
},
};
struct rte_flow_pattern_template *pts[1
] = {NULL};
…
pt = rte_flow_pattern_template_create(port_id, &pt_attr, patterns, &error);
…
pts[0
] = pt1;
…
range_flow_1 = rte_flow_async_create(port_id, queue_id, &attr, tbl,
rule_times, 0
, actions, 0
,
NULL, &error);