On 9/19/2026 6:10 PM, Medvedkin, Vladimir wrote:
On 9/16/2026 1:18 PM, Anatoly Burakov wrote:
Use the new flow graph API and the common parsing framework to implement
flow parser for SYN.
As a result of this migration, queue index validation has changed:
- queue is now validated at parse time against the configured number
of Rx
queues (nb_rx_queues), rather than at install time against the
hardware
maximum (IXGBE_MAX_RX_QUEUE_NUM)
- the per-function queue bound check in ixgbe_syn_filter_set() has been
removed as it is no longer needed
The syn filter tracking infrastructure is moved completely inside the new
engine and is removed from the rest of the driver.
Signed-off-by: Anatoly Burakov<[email protected]>
---
<snip>
-
- /* Support 2 priorities, the lowest or highest. */
- if (!attr->priority) {
- filter->hig_pri = 0;
- } else if (attr->priority == (uint32_t)~0U) {
- filter->hig_pri = 1;
- } else {
- memset(filter, 0, sizeof(struct rte_eth_syn_filter));
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ATTR_PRIORITY,
- attr, "Priority can be 0 or 0xFFFFFFFF");
- return -rte_errno;
- }
-
- return 0;
-}
<snip>
+
+ /* check priority */
+ if (attr->priority != 0 && attr->priority != (uint32_t)~0U) {
+ return rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ATTR_PRIORITY,
+ attr, "Priority can be 0 or 0xFFFFFFFF");
+ }
+
+ /* parse requested actions */
+ ret = ci_flow_check_actions(actions, &ap_param, &parsed_actions,
error);
+ if (ret)
+ return ret;
+
+ q_act = parsed_actions.actions[0]->conf;
+
+ syn_ctx->syn.queue = q_act->index;
+
+ /* Support 2 priorities. rte_flow priority 0 is highest */
+ syn_ctx->syn.hig_pri = attr->priority == 0;
seems like inverting priority with the previous implementation
Yes. I am not sure what to do about this, because the previous priority
is technically wrong, and my current code is correct as far as rte_flow
API semantics goes. Should this perhaps be a separate fix before the
refactor? To be perfectly blunt, I don't think many people use syn flows
so perhaps breaking backwards compatibility won't be a big issue.
+
+ return 0;
+}
<snip>
--
Thanks,
Anatoly