Custom ACL Based Metering #1889
Conversation
Describes the Custom ACL Based Metering (CABM) feature design in SONiC.
|
/azp run |
|
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
| priority = 1*3DIGIT ; rule priority. Valid values range | ||
| ; could be platform dependent | ||
|
|
||
| packet_action = "FORWARD"/"DROP"/"DO_NOT_NAT" ; action when the fields are matched |
There was a problem hiding this comment.
The packet_action and policer_action fields are a little bit confusing. For example, if the packet_action is DROP and policer is present, does that mean you only drop the traffic under a certain rate control?
There was a problem hiding this comment.
Each ACL rule can only specify a single action due to the ACL-Orch design and implementation.
For example, a rule specifying 'packet_action = DROP' cannot also include 'policer_action = M_POLICER_7'.
There was a problem hiding this comment.
I see. Can you clarify that in the db schema?
| ; matches are same as in ACL_RULE table. | ||
| actions = action-list ; list of actions for this table. | ||
| ; ["REDIRECT_ACTION", ... , "POLICER_ACTION"] | ||
| ``` |
There was a problem hiding this comment.
This may introduce some new dependency between ACL_TABLE , ACL_RULE and POLICER table. You may need to update code to handle the dependency.
There was a problem hiding this comment.
The design indeed introduces a dependency between ACL_RULE and POLICER tables, as ACL_RULE references POLICER_TABLE objects.
| 5. Create ACL Table: Add an ACL table in ACL_TABLE, referencing the custom table type and validates the configuration. | ||
| 6. Create ACL Rule: Add an ACL rule in ACL_RULE, referencing actions, including policer_action. | ||
| 7. Verify Rule Compatibility: ACL-Orch validates that the rule action compatibility with the associated ACL table type. | ||
| 8. Verify and Map Policer to SAI Object: Policer-Orch maps the policer_action name if it exists from CONFIG_DB to SAI object IDs. |
There was a problem hiding this comment.
In this design, can a policer be shared by multiple ACL rules? If it can be shared, how is the rate calculated?
For example, the policer limits the rate to 100pps, and the policer is shared by RULE_1 and RULE_2. Does that mean RULE_1 and RULE_2 share the 100pps?
There was a problem hiding this comment.
Yes, in this design, a single policer can be shared across multiple ACL rules. The rate specified in the policer will be applied cumulatively to all traffic matching any rule that references the shared policer.
|
Community review recording https://zoom.us/rec/share/29B51B0VyrGy4h27zWOcrKVfzRgto8ONES9h5QPRFjek-d2iFMRthW5mabfAG6TW.PN8n9aVAa1gO4D5u |
|  | ||
|
|
||
|
|
||
| 1. Query Capabilities on Initialization: ACL-Orch queries SAI to retrieve supported ACL actions, including SAI_ACL_ACTION_TYPE_SET_POLICER. |
There was a problem hiding this comment.
For now, the policer is only bound to mirror session. So if the capability query of SAI_ACL_ACTION_TYPE_SET_POLICER return true, does that mean policer can be applied to ACL rules? And is this only for Ingress only?
There was a problem hiding this comment.
As discussed in the meeting, if the capability can be determined by checking the ACL stage capabilities by reading SAI_SWITCH_ATTR_ACL_STAGE_INGRESS and SAI_SWITCH_ATTR_ACL_STAGE_EGRESS which are published in STATE DB at orchagent initialization, do we still need to add this new capability check?
There was a problem hiding this comment.
The capability query I mentioned here is the same as the one you referred to. The new additional step (4.) involves checking in the DB if the policer for ACL capability is true.
|
|
||
| #### **Configuration Flow** | ||
|
|
||
|  |
There was a problem hiding this comment.
If we are validating the ACL action policer capability based on information from STATE_DB, please use it in the diagram.
There was a problem hiding this comment.
The ACL-Orch saves the information in both STATE_DB and local DB. So in my case, I can just check the local DB.
| ##### ACL Table Type Table | ||
| When a new ACL table is created, SAI needs to receive a list of supported actions which the rules belonging to this table are allowed to use. | ||
| To support the new policer action, the custom table types table schema will be extended with a policer action attribute - **"POLICER_ACTION"** for the actions attribute field. | ||
|
|
There was a problem hiding this comment.
Please highlight the changes done on top of the existing tables for this feature.
| ... | ||
| + /* prevent deletion of policer that referenced by ACL rule. | ||
| + Note that new policer won't be referenced by any ACL rules initially */ | ||
| + must "not(../acl:sonic-acl/acl:ACL_RULE/acl:ACL_RULE_LIST[acl:policer_action=current()/name])" { |
There was a problem hiding this comment.
This may not be required, please double check.
There was a problem hiding this comment.
Sure, thanks. I'll update the HLD accordingly.
|
/azp run |
|
No pipelines are associated with this pull request. |
Describes the Custom ACL Based Metering (CABM) feature design in SONiC.