Custom ACL Based Metering #5
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shaygol
force-pushed
the
PBM
branch
2 times, most recently
from
9f6029d to
e77b658
Compare
shaygol
force-pushed
the
PBM
branch
2 times, most recently
from
d9b71e3 to
d509a07
Compare
- New 'AclRule' subclass: 'AclRulePolicer' - ACL rule table schema update - Unit Tests
* SRv6: add dscp_mode configuration for MySID entry * add a sync with CONFIG_DB to store MySID entry dscp mode * create a tunnel/tunnel term entry for uDT46 MySID entry (the tunnel is reused for the same dscp_mode) * add a new vs test Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: set MySID behavior flavor only when required Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: update to align with the latest configuration schema * align with the latest MySID config db schema * use reverse locator lookup to derive the locator in case of ambiguity Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: update to use the default values for SRV6_MY_LOCATORS Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: align with the latest spec for static configuration * align with new CONFIG_DB key format * use decap_dscp_mode for uN entry * update vs tests Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: fix MySID prefix mask calculation * use func_len to calculate MySID entry prefix for CONFIG_DB key * update the vstest to test different func_len values * add a test for the "locator reverse lookup" Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: fix log format Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: remove a skip condition for the DSCP mode vs tests Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> * SRv6: fix tunnels info bug Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> --------- Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com> Co-authored-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com> Co-authored-by: abdosi <58047199+abdosi@users.noreply.github.com>
…net#3452) * [BufferOrch] Use SAI bulk API to configure port, PG and queue What I did Make use of SAI set bulk API to improve switch boot up performance, especially in warm-boot and fast-boot scenarios. The general concept: First, tasks are processed one by one by corresponding process* methods which add the SAI operation with a context to a bulk buffer. Bulk buffers are split by DB operation. Bulk buffer is flushed to syncd using SAI bulk API, first DELETE operations are pushed in bulk then SET operations are pushed. Status code for each operation is updated in the task context structure. Lastly, corresponding process*Post methods are invoked to handle SAI status code and perform post set operations like enabling FC counter for a PG/queue upon success. This design allows re-use of all existing code that is written to handle one task at a time and a small change is needed to maintain task context persistence throughout steps 1-3.
…-net#3505) * portsorch: don't call updateDbPortOperStatus on all port types PORT_TABLE contains PortChannel oper_status entries which are not expected by portsorch which leads to warm/fastreboot failures like: ``` 2025 Feb 10 09:33:07.111055 sonic NOTICE swss#orchagent: :- bake: foundPortConfigDone = 1 2025 Feb 10 09:33:07.111080 sonic NOTICE swss#orchagent: :- bake: foundPortInitDone = 1 2025 Feb 10 09:33:07.111395 sonic NOTICE swss#orchagent: :- bake: m_portTable->getKeys 263 2025 Feb 10 09:33:07.111403 sonic NOTICE swss#orchagent: :- bake: portCount = 257, m_portCount = 0 2025 Feb 10 09:33:07.111403 sonic ERR swss#orchagent: :- bake: Invalid port table: portCount, expecting 257, got 261 ``` Fixes sonic-net/sonic-buildimage#21688
*sonic-swss: Code changes for WRED and ECN statistics (sonic-net#2750) New flex counter group for per-Queue WRED and ECN statistics New flex counter group for per-Port WRED and ECN statistics Why I did it Implemented as per the HLD : https://github.com/sonic-net/SONiC/blob/master/doc/qos/ECN_and_WRED_statistics_HLD.md How I verified it Verfied it using Marvell DUT and SWSS unit tests. Details if related Two new flex counters added for per-Queue and per-Port WRED ECN statistics. Build dependency on sonic-swss-common pull request : sonic-net/sonic-swss-common#777
…r ECMP/LAG switch hash configuration (sonic-net#3481) * added SAI_NATIVE_HASH_FIELD_IPV6_FLOW_LABEL to the hash-field table Why I did it Need to support SAI_NATIVE_HASH_FIELD_IPV6_FLOW_LABEL parameters for hash calculation How I verified it Configure SAI_NATIVE_HASH_FIELD_IPV6_FLOW_LABEL via CLI, check /var/log/syslog
* Code owners update for bufferorch, muxorch and acl
…agMember for strip tag (sonic-net#3343) What I did Added child_ports check in addLagMember and removeLagMember for strip tag Why I did it portorch sets LAG member's strip tag when adding subport: // Change hostif vlan tag for the parent port only when a first subport is created if (parentPort.m_child_ports.empty()) { if (!setHostIntfsStripTag(parentPort, SAI_HOSTIF_VLAN_TAG_KEEP)) but if a new member is added later, in addLagMember function, it does not handle strip tag anymore. Cause the new added lag member has wrong tag mode.
…-net#3520) *What I did: Added Change to Skip Route Programming if NH is link/oper down. With Scale Route testing of 60K+ routes when we toggle all the interfaces[14+ interface back to back] as done here: https://github.com/sonic-net/sonic-mgmt/blob/master/tests/snappi_tests/multidut/bgp/test_bgp_outbound_uplink_multi_po_flap.py we see because of slowness of FRR Route APP_DB processing compare to Link Notification Handling where we have updated the Nexthop Group as part of Link Notification handling to point to default route via sonic-net#3389 [if eligible] FRR slowness can reprogram the Route back to Nexthop which is link down. This change is similar to sonic-net#3394 which was done for Nexthop Group.
…-net#3517) * Set Port UPDATE_DSCP attribute when TC_TO_DSCP map is attached What I did Set Port SAI attribute SAI_PORT_ATTR_UPDATE_DSCP when TC_TO_DSCP map is attached to the port. Why I did it Some vendor SAI expects Sonic to set this attribute explicitly when TC_TO_DSCP map is attached to the port to modify DSCP value of the packet.
* Add appliance entry validation (sonic-net#3494) - Do not allow more than 1 entry in DASH Appliance table. - Do not allow DASH VNET creation before DASH Appliance entry creation. - DASH ENI already has similar check for Appliance entry.
* [smartswitch] Add support for ENI Based Forwarding HLD: sonic-net/SONiC#1842 Requires sonic-net/sonic-swss-common#976 Add DashEniFwdOrch which installs ACL rules to Redirect the DASH packet to corresponding DPU
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WIP: