Enhancement: make ACL table group member priority configurable (currently hardcoded to 100 in PortsOrch::bindAclTable)

[AnantKishorSharma]

Is it platform specific

generic (generic code path; impact is most visible on platforms whose ACL table group type resolves to SEQUENTIAL, which is also the SAI default)

Importance or Severity

Medium

Description of the enhancement

When a CONFIG_DB ACL_TABLE is bound to a port, PortsOrch::bindAclTable() creates the ACL table group member with SAI_ACL_TABLE_GROUP_MEMBER_ATTR_PRIORITY hardcoded to 100 for every member. There is no CONFIG_DB / YANG knob to influence it.

Per SAI, this member priority is the "ACL table priority" that governs both table lookup order (SEQUENTIAL groups) and action-conflict resolution (PARALLEL groups). Pinning every member to the same constant removes the operator's only lever over multi-table behavior on a shared bind point, and makes ordering non-deterministic when two or more tables share a port + stage.

This enhancement proposes exposing the member priority as an optional, validated CONFIG_DB field — mirroring the P4Orch ACL path, which already drives this exact attribute from configuration.

It is the natural follow-up to #4671 / #4672 (open, under review), which makes the ACL table group type capability-driven instead of hardcoding PARALLEL. Once the group type is reported honestly (and defaults to SEQUENTIAL per SAI), member priority becomes load-bearing and must be controllable.

Current Behavior

orchagent/portsorch.cpp, PortsOrch::bindAclTable():

member_attr.id = SAI_ACL_TABLE_GROUP_MEMBER_ATTR_PRIORITY;
member_attr.value.u32 = 100;   // hardcoded for ALL members
member_attrs.push_back(member_attr);

The group type in the same path is now queried, not hardcoded (#4672):

group_attr.id = SAI_ACL_TABLE_GROUP_ATTR_TYPE;
group_attr.value.s32 = querySupportedAclTableGroupType(gSwitchId);

Consequences of the hardcoded 100 (priority is valid for both group types per SAI):

• SEQUENTIAL group: priority defines table lookup order. Equal priority across members ⇒ SAI falls back to a "first come basis," i.e. order depends on bind sequence. Tables are tracked in an unordered set (m_ingress_acl_tables_uset / m_egress_acl_tables_uset), so the order of two+ tables on the same port + stage (e.g. a data ACL + a mirror/EVERFLOW table) is effectively nondeterministic / not reproducible across reloads.
• PARALLEL group: priority resolves conflicting actions between tables. Equal priority ⇒ inter-table conflict resolution is undefined on a shared bind point.
• Range is platform-reported via SAI_SWITCH_ATTR_ACL_TABLE_MINIMUM/MAXIMUM_PRIORITY. 100 is a blind constant with no guarantee it is meaningful, mid-range, or even in-range on a given ASIC.

So the gap affects both group types — not only SEQUENTIAL.

The capability already exists end-to-end — the P4Orch path drives the same attribute from a parsed, validated value (orchagent/p4orch/acl_table_manager.cpp):

acl_mem_attr.id = SAI_ACL_TABLE_GROUP_MEMBER_ATTR_PRIORITY;
acl_mem_attr.value.u32 = acl_table.priority;   // from APP_DB "priority", validated >= 0

Schema gap: CONFIG_DB ACL_TABLE_LIST (sonic-acl.yang) exposes only ACL_TABLE_NAME, policy_desc, type, stage, services, ports — no priority leaf, so inter-table ordering / conflict precedence cannot be expressed in config today.

Proposed Behavior

Add configurable ACL-table member priority:

1. YANG / CONFIG_DB: add an optional priority leaf to ACL_TABLE_LIST in sonic-acl.yang (uint32), defaulting to 100 for backward compatibility.
2. orchagent: plumb the value through AclTable / AclOrch::bindAclTable() → AclTable::bind() → PortsOrch::bindAclTable() into SAI_ACL_TABLE_GROUP_MEMBER_ATTR_PRIORITY, replacing the hardcoded 100.
3. Validation: validate the configured value against the switch-reported range [SAI_SWITCH_ATTR_ACL_TABLE_MINIMUM_PRIORITY, SAI_SWITCH_ATTR_ACL_TABLE_MAXIMUM_PRIORITY], consistent with SAI and the existing P4Orch validation.
4. Backward compatibility: absent the field, behavior is identical to today (100), so existing configs are unaffected.
5. Tests: YANG model tests for the new leaf (valid/invalid/default) and orchagent VS tests asserting the configured priority reaches the group member attribute.

This mirrors the P4Orch ACL behavior and gives operators deterministic control over table evaluation order (SEQUENTIAL) and action-conflict precedence (PARALLEL).

Related

• [orchagent] ACL table group type hardcoded to PARALLEL instead of querying SAI capability #4671 / orchagent: query ACL table group type capability instead of hardcoding PARALLEL #4672 — query ACL table group type capability instead of hardcoding PARALLEL (open, under review). Logical prerequisite: once group type is honest and defaults to SEQUENTIAL per SAI, configurable member priority is required for deterministic multi-table behavior.