- session-timeout in the range of 1 to 3600 seconds with default value of 15 seconds
-- session-timeout should be multipler of keepalive-timer value
+- session-timeout should be multiplier of keepalive-timer value
```
@@ -642,7 +642,7 @@ Sonic#show mclag brief
**Figure 4: Local Dynamic MAC upstream to ICCPd Flow Diagram**
### 4.1.3 Remote MAC Processing
-Below diagram shows the flow of MAC address programing learned from ICCP.
+Below diagram shows the flow of MAC address programming learned from ICCP.
@@ -669,7 +669,7 @@ Local Ip: 192.168.1.1
Peer Ip: 192.168.1.2
Peer Link Interface: PortChannel30
Keepalive time: 1
-sesssion Timeout : 15
+session Timeout : 15
Peer Link Mac: b8:6a:97:73:6c:96
Role: Active
MCLAG Interface: PortChannel50
diff --git a/doc/mclag/Sonic-mclag-hld.md b/doc/mclag/Sonic-mclag-hld.md
index 3cd37f62878..8d9e01db9ce 100644
--- a/doc/mclag/Sonic-mclag-hld.md
+++ b/doc/mclag/Sonic-mclag-hld.md
@@ -106,7 +106,7 @@ The features below are not supported currently, may provide solutions in future
- More consistency checking, both between peer switches and MLAG port channels configured on the switches, e.g. port speed configuration
- Peer-link with a detection mechanism, and with robust "split brain" detection
- Configurable peer master/slave roles for the peer switches
-- VRRP/VARP for active/active gateway redundency
+- VRRP/VARP for active/active gateway redundancy
- Add feature support across MLAGs (e.g. STP, IGMP snooping, DHCP Relay)
- Make sure isolation ACL is installed in the ASIC table before MCLAG enabled portchannel is active
@@ -142,7 +142,7 @@ Will MC-LAG work if there is no physical connection between the peers? In theory
## 5.2. ICCPd State machines
-Lite version support “ICCP Connection State Machine”，shown as followings:
+Lite version support “ICCP Connection State Machine”，shown as following:
The ICCP Connection state machine is defined to have six states in RFC 7275 section 4.2.1, as below.
- NONEXISTENT: This state is the starting point for the state machine. It indicates that no ICCP connection exists between the PEs.
@@ -592,13 +592,13 @@ Adding the following logic:([PR#810](https://github.com/sonic-net/sonic-swss/pul
Adding the following logics:
-- If the port has the attribute ‘learn_mode’ in CFG_DB, read the attribute and set this attribute in APP_DB. If ‘learn_mode’ is set to ‘disabled’, the MAC learning of this port is disbled.
+- If the port has the attribute ‘learn_mode’ in CFG_DB, read the attribute and set this attribute in APP_DB. If ‘learn_mode’ is set to ‘disabled’, the MAC learning of this port is disabled.
## 9.6. portsorch changes
Adding the following logics:
-- Listening new APP_DB events, enable or disable to learn interface MACs. If ‘learn_mode’ attribute of one port is set to ‘disabled’, the MAC learning of this port is disbled.([PR#809](https://github.com/sonic-net/sonic-swss/pull/809))
+- Listening new APP_DB events, enable or disable to learn interface MACs. If ‘learn_mode’ attribute of one port is set to ‘disabled’, the MAC learning of this port is disabled.([PR#809](https://github.com/sonic-net/sonic-swss/pull/809))
- Add LAG name map to counter table, so that ‘show mac’ can display the MACs learned from LAG ports. ([PR#808](https://github.com/sonic-net/sonic-swss/pull/808))
## 9.7. intfmgr changes
@@ -659,10 +659,10 @@ Adding the following logics:
Adding the following logics:
-- If the PortChannel has the attribute 'learn_mode' in CFG_DB, read the attribute and set this attribute in APP_DB. If 'learn_mode' is set to 'disabled', the MAC learning of LAG port is disbled.
+- If the PortChannel has the attribute 'learn_mode' in CFG_DB, read the attribute and set this attribute in APP_DB. If 'learn_mode' is set to 'disabled', the MAC learning of LAG port is disabled.
- When warm-reboot teammgr gets MAC from saved LACP PDU and update port-channel's MAC before port-channel member port sending any LACP PDU.
# 10. Test
-A separete test spec is provided for community to review.
+A separate test spec is provided for community to review.
diff --git a/doc/mgmt/Management_Framework_Transformer_Component_Support_For_Model_based_Replace_And_Delete.md b/doc/mgmt/Management_Framework_Transformer_Component_Support_For_Model_based_Replace_And_Delete.md
index bfa02ff89ef..dfa67382cfe 100644
--- a/doc/mgmt/Management_Framework_Transformer_Component_Support_For_Model_based_Replace_And_Delete.md
+++ b/doc/mgmt/Management_Framework_Transformer_Component_Support_For_Model_based_Replace_And_Delete.md
@@ -34,7 +34,7 @@ The data resource is identified by the RESTCONF target resource URI that can be
# 2 Background
Replacing data resource with PUT operation at any depth of YANG model has been a challenge over the last few releases and there was limited support to replace only the data translated from the request payload instead of entire data resource yang hierarchy.
-Current DELETE operation resulted in the deletion of only the target data resource and not the heirarchy beneath it.
+Current DELETE operation resulted in the deletion of only the target data resource and not the hierarchy beneath it.
This feature attempts to overcome this behaviour and support the PUT & DELETE at any yang depth and avoid the applications to handle this in their callbacks especially the post transformer callback.
# 3 Requirements
@@ -70,14 +70,14 @@ This feature attempts to overcome this behaviour and support the PUT & DELETE at
2) The DELETE request from northbound will follow the same procedures as point 1.2 in REPLACE flow as detailed above except 1.2)6) which is not required for north bound DELETE operation.
-3) Current annotation of "get-validate" will be changed to "validate-xfmr"so that it can be used for CRUD cases as well as GET. During traversal both for REPLACE and DELETE flow, validate transformer callbacks will be invoked and if they identify the node to be not valid for the request, the node and its child heirarchy will not be processed.
+3) Current annotation of "get-validate" will be changed to "validate-xfmr"so that it can be used for CRUD cases as well as GET. During traversal both for REPLACE and DELETE flow, validate transformer callbacks will be invoked and if they identify the node to be not valid for the request, the node and its child hierarchy will not be processed.
-4) The DB operations for all the tables in the final translated map will be continued to be excercised alongside CVL as in the current design.
+4) The DB operations for all the tables in the final translated map will be continued to be exercised alongside CVL as in the current design.
After completion of PUT/REPLACE operation, a GET operation should find/fetch only the data releavent to the new config data asked by the client in the request payload.Similarly after completion of DELETE operation, a GET operation should fetch no data.
**Limitations:**
-1. Defaults will be applied only for DB instances mapped to the nodes in PUT payload and its child heirarchy belonging to the same table.Refer 1.1 4) above.
+1. Defaults will be applied only for DB instances mapped to the nodes in PUT payload and its child hierarchy belonging to the same table.Refer 1.1 4) above.
2. No default values will be applied when fields/DB table instances having default value are marked for delete in the GET-like delete flow (for both PUT and DELETE operations).Refer example 7 in the use cases section 4.1 below.
If the north bound operation is DELETE and when the target node is a leaf having default, the default value will be reset instead of deleting the leaf node (existing behavior).
@@ -717,7 +717,7 @@ final node IFF its a list instance
7. Target is at a yang node at a
higher depth in yang and the
- child hierachy spans multiple
+ child hierarchy spans multiple
tables mapped to child list
and containers with and without
defaults
@@ -843,7 +843,7 @@ TBL-C1|val-k1
TBL-C1D1|keyC1D1
------------------
leaf-t: valt
- leaf-u: valu (default)
+ leaf-u: value (default)
TBL-C1E1|val-q
------------------
leaf-o: valo (default)
@@ -887,7 +887,7 @@ This annotation will be useful in cases where DB table has data not only from th
**Dynamic annotation**
- If the table returned by table-xfmr is owned by the yang node for a given instance/key but for some other key it does not own the table then in such case set dynamic flag **\*isNotTblOwner** to true and don't use static annotation. When returning a single table as per the key in URI, the dynamic flag can be filled by the table-xfmr callback.
-- when multiple tables are returned by the table-xfmr for URI targeted at whole list then do not set the flag for table-owner becuase infra will process every instance for every table, and to traverse the child yang hierarchy the table xfmr will be invoked per instance again that will map to single table.
+- when multiple tables are returned by the table-xfmr for URI targeted at whole list then do not set the flag for table-owner because infra will process every instance for every table, and to traverse the child yang hierarchy the table xfmr will be invoked per instance again that will map to single table.
**Note:** Do not mix static table-owner annotation with dynamic, a static table-owner annotation will take precedence.
@@ -971,13 +971,13 @@ GET like traversal of the yang hierarchy beneath the target URI to identify the
**Static annotation (existing annotation)**
-Use the **virtual-table:true** annotation where there is table-xfmr annotation and the yang node doesn't map to any real DB table but the node needs to traversed to the reach child yang hierarchy wher DB mappings exist.
+Use the **virtual-table:true** annotation where there is table-xfmr annotation and the yang node doesn't map to any real DB table but the node needs to traversed to the reach child yang hierarchy where DB mappings exist.
By default all tables identified at a yang node are considered as mapped to real DB table (virtual-table:false)
**Dynamic annotation (existing annotation)**
If a table returned by table-xfmr for a given key in URI maps to a real DB table but for another given key it doesn't map to a DB table then in such case set dynamic flag ***inParams.isVirtualTbl = true** and don't use static annotation.
-When the table xfmr returns a single table as per the key in URI, the dynamic flag for virtual table can be filled by the callback.When multiple tables are returned by the table-xfmr for URI targeted at whole list then do not set the flag becuase infra will process every instance in every table and the table xfmr will be invoked again per instance that will map to single table.
+When the table xfmr returns a single table as per the key in URI, the dynamic flag for virtual table can be filled by the callback.When multiple tables are returned by the table-xfmr for URI targeted at whole list then do not set the flag because infra will process every instance in every table and the table xfmr will be invoked again per instance that will map to single table.
**Note:** Do not mix static annotation with dynamic, a static annotation will take precedence.
@@ -1270,7 +1270,7 @@ ________________________________________________________________________________
- PUT payload containing instances mapped with table-owner false annotation should not result in swapping the whole table-entry with new payload keeping the other attributes in the table-entry, that are not mapped in the request yang intact.
- PUT request URI targeted at list instance not present in DB should create the instance with attributes from payload.
- PUT request URI targeted at leaf/leaf-list node should update the value with new value in payload.
- - DELETE request URI targeted at whole list/list-instance should delete all list instances/targeted list-instance respectively,that exist in DB, including the relevant insances in the child yang hierarchy.In case of non table-owner only the attributes in the yang hierarchy should be deleted.Yang nodes in the child yang hierarchy having virtual table mapping should not be marked for delete.
- - DELETE request URI targeted at container should delete only the attributes under that container.Child yang hierachy should be traversed and relevant instances should be deleted.Yang nodes in the child yang hierarchy having virtual table mapping should not be marked for delete.
+ - DELETE request URI targeted at whole list/list-instance should delete all list instances/targeted list-instance respectively,that exist in DB, including the relevant instances in the child yang hierarchy.In case of non table-owner only the attributes in the yang hierarchy should be deleted.Yang nodes in the child yang hierarchy having virtual table mapping should not be marked for delete.
+ - DELETE request URI targeted at container should delete only the attributes under that container.Child yang hierarchy should be traversed and relevant instances should be deleted.Yang nodes in the child yang hierarchy having virtual table mapping should not be marked for delete.
- DELETE request targeted at leaf node should delete the corresponding DB attribute in mapped table-entry.If leaf has yang default it should reset to default.
- DELETE request targeted at leaf-list instance should delete the specific instance and if the request is targeted at entire leaf-list then the corresponding attribute in table-entry should get deleted.
\ No newline at end of file
diff --git a/doc/mgmt/OpenConfig_PortChannel_Interface.md b/doc/mgmt/OpenConfig_PortChannel_Interface.md
index 7980dcaae32..7ca81dc85ef 100644
--- a/doc/mgmt/OpenConfig_PortChannel_Interface.md
+++ b/doc/mgmt/OpenConfig_PortChannel_Interface.md
@@ -148,7 +148,7 @@ module: openconfig-interfaces
| REST | REpresentative State Transfer |
| gNMI | gRPC Network Management Interface: used to retrieve or manipulate the state of a device via telemetry or configuration data |
| XML | eXtensible Markup Language |
-| Aggregate | Interchangable with portchannel |
+| Aggregate | Interchangeable with portchannel |
# 1 Feature Overview
diff --git a/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md b/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md
index 6ff37a05357..7a72999906b 100644
--- a/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md
+++ b/doc/mgmt/SONiC_Design_Doc_Unified_FRR_Mgmt_Interface.md
@@ -94,7 +94,7 @@ This feature extends and provides unified configuration and management capabilit
### 1.1.1 Functional Requirements
1. Extend Unified mode for full FRR-BGP config and management in SONiC
- 2. Ability to start frrcfgd (new FRR config deamon fully based on config-DB events) or bgpcfgd (template based legacy daemon) based on frr_mgmt_framework_config field with "true"/"false" in DEVICE_METADATA table
+ 2. Ability to start frrcfgd (new FRR config daemon fully based on config-DB events) or bgpcfgd (template based legacy daemon) based on frr_mgmt_framework_config field with "true"/"false" in DEVICE_METADATA table
3. Add frrcfgd daemon (sonic-buildimage/src/sonic-frr-mgmt-framework) and integrate with FRR-BGP for features supported in SONiC
3. Support for retrieval of FRR-BGP state and statistics information
4. For backward compatibility retain access to FRR UI (vtysh) for managing features that are NOT in conflict with SONiC features
@@ -386,7 +386,7 @@ remove_private_as_enabled = "true" / "false" ; Remove private ASNs in outbo
replace_private_as = "true" / "false" ; Replace private ASNs with our ASN in outbound update
remove_private_as_all = "true" / "false" ; Apply to all AS numbers
allow_as_in = "true" / "false" ; Accept as-path with my AS present in it
-allow_as_count = 1*3DIGIT ; Number of occurences of AS number
+allow_as_count = 1*3DIGIT ; Number of occurrences of AS number
allow_as_origin = "true" / "false" ; Only accept my AS in the as-path if the route was originated in my AS
cap_orf = "send" / "receive" / "both" ; Outbound route filtering capability
route_server_client = "true" / "false" ; Configure a neighbor as Route Server client
@@ -474,7 +474,7 @@ remove_private_as_enabled = "true" / "false" ; Remove private ASNs in outbo
replace_private_as = "true" / "false" ; Replace private ASNs with our ASN in outbound update
remove_private_as_all = "true" / "false" ; Apply to all AS numbers
allow_as_in = "true" / "false" ; Accept as-path with my AS present in it
-allow_as_count = 1*3DIGIT ; Number of occurences of AS number
+allow_as_count = 1*3DIGIT ; Number of occurrences of AS number
allow_as_origin = "true" / "false" ; Only accept my AS in the as-path if the route was originated in my AS
cap_orf = "send" / "receive" / "both" ; Outbound route filtering capability
route_server_client = "true" / "false" ; Configure a neighbor as Route Server client
@@ -499,7 +499,7 @@ name = 1*255VCHAR ; route map set name
key = ROUTE_MAP|route_map_name|stmt_name ;
route_map_name = 1*64VCHAR ; route map name
-stmt_name = 1*64VCHAR ; statment name
+stmt_name = 1*64VCHAR ; statement name
route_operation = "ACCEPT" / "REJECT"; Permit/Deny operation
match_interface = 1*64VCHAR ; Match interface name
match_prefix_set = 1*64VCHAR ; Match prefix sets
@@ -606,7 +606,7 @@ as_path_set_member = string list ; AS path list
### 3.2.1.16 DEVICE_METADATA
```JSON
-; Ability to start frrcfgd (new FRR config deamon fully based on config-DB events) or bgpcfgd (template based legacy daemon) based on 'frr_mgmt_framework_config' field with "true"/"false"
+; Ability to start frrcfgd (new FRR config daemon fully based on config-DB events) or bgpcfgd (template based legacy daemon) based on 'frr_mgmt_framework_config' field with "true"/"false"
;
;Status: stable
key = localhost ; name must be unique
@@ -785,7 +785,7 @@ module: openconfig-routing-policy
##### 3.6.2.1.4 BGP Neighbor Address family mode commands
|Command Description |CLI Command |
|:-----------------|:---------------|
-|Activate a BGP neighor for a specific address family|sonic(config-router-bgp-neighbor-af)#activate|
+|Activate a BGP neighbor for a specific address family|sonic(config-router-bgp-neighbor-af)#activate|
|Config as-path acceptance with own ASN|sonic(config-router-bgp-neighbor-af)#allowas-in \ [origin] |
|Specify route policy map to neighbor mapping|sonic(config-router-bgp-neighbor-af)#route-map \ {in \| out} |
| Use addpath to advertise all paths to a neighbor |sonic(config-router-bgp-neighbor-af)# addpath-tx-all-paths |
diff --git a/doc/mgmt/SONiC_YANG_Model_Guidelines.md b/doc/mgmt/SONiC_YANG_Model_Guidelines.md
index 9d03f1296d4..191346cc4d3 100644
--- a/doc/mgmt/SONiC_YANG_Model_Guidelines.md
+++ b/doc/mgmt/SONiC_YANG_Model_Guidelines.md
@@ -551,7 +551,7 @@ container INTERFACE {
}
......
```
-In the example above if the config DB contains an INTERFACE table with single key element then it will be associted with the INTERFACE_LIST and if contains 2 key elements then it will be associated with INTERFACE_IPADDR_LIST
+In the example above if the config DB contains an INTERFACE table with single key element then it will be associated with the INTERFACE_LIST and if contains 2 key elements then it will be associated with INTERFACE_IPADDR_LIST
#### Example 2: Keys with same number of elements of same type (NOT Allowed case 1)
@@ -884,7 +884,7 @@ module sonic-acl {
}
must "(/scommon:operation/scommon:operation != 'DELETE') or " +
"(current()/../../../ACL_TABLE/ACL_TABLE_LIST[table_name=current()]/type = 'L3')" {
- error-message "Type not staisfied.";
+ error-message "Type not satisfied.";
}
}
diff --git a/doc/mgmt/gnmi/SONiC_GNMI_Server_Interface_Design.md b/doc/mgmt/gnmi/SONiC_GNMI_Server_Interface_Design.md
index 23363f8428e..22d18b4bda6 100644
--- a/doc/mgmt/gnmi/SONiC_GNMI_Server_Interface_Design.md
+++ b/doc/mgmt/gnmi/SONiC_GNMI_Server_Interface_Design.md
@@ -223,7 +223,7 @@ With CONFIG_DB schema:
elem {name: "CONFIG_DB"} elem {name: "localhost"} elem {name: "DEVICE_NEIGHBOR"}
}
encoding: JSON_IETF
- ++++++++ Recevied get response: ++++++++
+ ++++++++ Received get response: ++++++++
notification {
update {
path {
@@ -253,7 +253,7 @@ With CONFIG_YANG schema:
elem {name: "CONFIG_DB"} elem {name: "localhost"} elem {name: "sonic-device_neighbor:sonic-device_neighbor"}
}
encoding: JSON_IETF
- ++++++++ Recevied get response: ++++++++
+ ++++++++ Received get response: ++++++++
notification {
update {
path {
@@ -295,7 +295,7 @@ With CONFIG_DB schema:
json_ietf_val: "eth1"
}
}
- ++++++++ Recevied set response: ++++++++
+ ++++++++ Received set response: ++++++++
response {
path {
origin: "sonic_db"
@@ -329,7 +329,7 @@ With CONFIG_YANG schema:
json_ietf_val: "eth1"
}
}
- ++++++++ Recevied set response: ++++++++
+ ++++++++ Received set response: ++++++++
response {
path {
origin: "sonic_yang"
@@ -394,7 +394,7 @@ SetRequest message will be:
json_ietf_val: "{\"DEVICE_NEIGHBOR/Ethernet8/name\":\"Servers1\", \"DEVICE_NEIGHBOR/Ethernet8/port\":\"eth0\", \"DEVICE_NEIGHBOR/Ethernet96/name\":\"Servers23\", \"DEVICE_NEIGHBOR/Ethernet96/port\":\"eth0\", ...}"
}
}
- ++++++++ Recevied set response: ++++++++
+ ++++++++ Received set response: ++++++++
response {
path {
origin: "sonic_db"
@@ -414,7 +414,7 @@ SetRequest message will be:
All successful changes for ConfigDB made through the gNMI SET RPC will be saved to /etc/sonic/config_db.json.
-If the target database is not ConfigDB, we can't guarantee persisitence.
+If the target database is not ConfigDB, we can't guarantee persistence.
#### 1.2.1.7 Heartbeat and Reprogram
diff --git a/doc/mgmt/gnmi/gNMI_Subscription_for_YangData.md b/doc/mgmt/gnmi/gNMI_Subscription_for_YangData.md
index f9e2bb2d0be..e8bb745faaf 100644
--- a/doc/mgmt/gnmi/gNMI_Subscription_for_YangData.md
+++ b/doc/mgmt/gnmi/gNMI_Subscription_for_YangData.md
@@ -90,8 +90,8 @@ to support gNMI subscriptions and wildcard paths for YANG defined paths.
### 1.1 Introduction
-SONiC Telemetry service suports gNMI Get, Set and Subscribe RPCs for DB paths and sonic-yang based paths.
-It also suppots Get and Set for OpenConfig YANG paths that are part of **sonic-mgmt-common** repository.
+SONiC Telemetry service supports gNMI Get, Set and Subscribe RPCs for DB paths and sonic-yang based paths.
+It also supports Get and Set for OpenConfig YANG paths that are part of **sonic-mgmt-common** repository.
This design document describes proposed enhancements to support gNMI Subscribe RPC for these OpenConfig yang paths.
### 1.2 Requirements
@@ -142,7 +142,7 @@ Proposed enhancements should not affect any of the existing functionalities of t
### 1.3 Translib Overview
Translib is a golang library for reading and writing YANG model based data to redis DB or non-DB data source.
-OpenConfig YANG models and correspinding translation code will be plugged into translib.
+OpenConfig YANG models and corresponding translation code will be plugged into translib.
These application components are called *app modules*.
Northbound API servers, like REST/gNMI servers, can call translib functions likes `Get()`, `Create()`, `Delete()` to process the request they received.
Translib then invokes corresponding app modules to translate the YANG and and perform actual read/write operations.
@@ -373,7 +373,7 @@ This approach tends to result in Translib sending stream of smaller chunks of da
A `SubscribeResponse` with SyncComplete=true is pushed to the queue after data chunks are pushed.
Once the initial data responses are complete, the `Subscribe()` function ends.
-But the notification handler will continue to run until gNMI servers sends a cancel signal (through the cannel it passed to the `Subscribe()` function) or a redis PubSub read fails.
+But the notification handler will continue to run until gNMI servers sends a cancel signal (through the channel it passed to the `Subscribe()` function) or a redis PubSub read fails.
#### 2.8.3 DB key to YANG Path mapping
@@ -412,7 +412,7 @@ Following table lists how translib re-interprets the redis keyspace notification
|-------------|-----------------------|--------------------|---------------|-----------------|----------|
| hset/hdel | No | No | None | Ignore | Entry was created and deleted in quick succession. We cannot process them since we lost the values already. |
| | No | Yes | Add to cache | Key create | |
-| | Yes | No | None | Ignore | Update follwed by delete in quick succession. We have already lost the updated value. Hence nothing to be done here. There will be a *del* event next which will send delete notification. |
+| | Yes | No | None | Ignore | Update followed by delete in quick succession. We have already lost the updated value. Hence nothing to be done here. There will be a *del* event next which will send delete notification. |
| | Yes | Yes | Update cache | Entry update | |
| del | No | No | None | Ignore | Entry was added and deleted in quick succession. We skip delete since we would have already skipped the create. |
| | No | Yes | None | Ignore | Should not happen. |
@@ -426,7 +426,7 @@ It will be destroyed when the session is closed (i.e, when Subscribe RPC ends).
Translib notification handler will calculate the modified DB fields by comparing the latest DB entry with the OnChange cache entry.
Notification is ignored if there are no changes relevant to current subscribe paths.
-Redis key create/delete and create/update/delete of any of the fields peresent in the DB mapping are considered processed further.
+Redis key create/delete and create/update/delete of any of the fields present in the DB mapping are considered processed further.
A `SubscribeResponse` object will be constructed as listed below:
| DB change type | SubscribeResponse contents |
@@ -475,7 +475,7 @@ If the subscribe path is not mapped to any DB table (non-DB data) and does not h
To detect deleted resources, gNMI server will maintain previous iteration's snapshot in a {path, YGOT object} cache.
Current iteration's data is compared against this cache to identify deleted objects or attributes.
-Cache will be updated wih the current values at the end of each iteration.
+Cache will be updated with the current values at the end of each iteration.
YGOT `ygot.Diff()` like logic can be used to compare two YGOT objects.
We observed performance issues with `ygot.Diff()` API, hence it will not be used directly.
@@ -594,8 +594,8 @@ does not contain wildcards.
Translib `Stream()` API current data is through the existing `Get()` flow.
Wildcard paths cannot be passed to these functions due to limitations in the YGOT.
-An alterante approach is to extend app module's `processSubscribe()` scope to return all specific paths of a wildcard path.
-However this will not be practical for the app modules if non-DB data source does not provide APIs to retrive object keys (equivalent of redis KEYS or SCAN).
+An alternate approach is to extend app module's `processSubscribe()` scope to return all specific paths of a wildcard path.
+However this will not be practical for the app modules if non-DB data source does not provide APIs to retrieve object keys (equivalent of redis KEYS or SCAN).
There is no standard "non-DB data access" layer in translib today.
Hence the current design does not support wildcard paths for non-DB data.
Future releases can enhance this based on how non-DB data access evolves in translib.
@@ -641,7 +641,7 @@ func IsSubscribeSupported(req IsSubscribeRequest) ([]*IsSubscribeResponse, error
type IsSubscribeRequest struct {
Paths []IsSubscribePath
Session *SubscribeSession
- // client info for authetication & accounting
+ // client info for authentication & accounting
}
type IsSubscribePath struct {
diff --git a/doc/mgmt/gnmi/gnoi_healthz_hld.md b/doc/mgmt/gnmi/gnoi_healthz_hld.md
index fb9910bee02..0b03fa90932 100644
--- a/doc/mgmt/gnmi/gnoi_healthz_hld.md
+++ b/doc/mgmt/gnmi/gnoi_healthz_hld.md
@@ -69,7 +69,7 @@ The [Healthz](https://github.com/openconfig/gnoi/blob/main/healthz/healthz.proto
```
// The Healthz service provides access to the status of a path on the
-// system. Addtitionally it allows the implementor to provide path specific
+// system. Additionally it allows the implementer to provide path specific
// diagnositic data into the status return.
//
// Healthz is expected to work in conjunction with the component OC model.
@@ -179,7 +179,7 @@ Supported Paths for Get:
Get Sequence Flow
1. The Get RPC handler translates the incoming gNMI Path in the Get request to the correct component and derives the related information for the log level indicated.
-2. For the above supoorted paths, a call to HealthzCollect is made through the DBUS client with the component name, log level, and a persistent_storage flag to indicate if the artifacst should be stored in persistent storage. This in turn invokes the DBUS endpoint of the host service via the module `debug_info`.
+2. For the above supported paths, a call to HealthzCollect is made through the DBUS client with the component name, log level, and a persistent_storage flag to indicate if the artifacst should be stored in persistent storage. This in turn invokes the DBUS endpoint of the host service via the module `debug_info`.
3. The host service module `debug_info.collect` collects all the artifacts for a given board type. Depending on the log level and board type input, the relevant log files, DB snapshots, counters, record files, and various command outputs are collected for multiple components and aggregated under a specified artifact directory in the host. Once complete, the directory is compressed to a `*.tar.gz` file ready to be streamed.
4. In. the meantime, the frontend keeps polling for the artifact to be ready with a call to HealthzCheck through the DBUS client `debug_info.check`.
5. Once the artifact tar file is ready, the artifact details (filename, size, checksum) with the unique ID string are sent in the Get response back to the client.
@@ -212,9 +212,9 @@ message ArtifactHeader {
// File artifacts should use the defined FileArtifactType.
// Proto artifacts should either use the generic ProtoArtifactType
// which means the artifact is made up a sequence of proto.Any
- // messages which can be deserialized directly into thier message
+ // messages which can be deserialized directly into their message
// types. Otherwise the implementer can provide a specific artifact type
- // which can add any additional metadata the implementor wants and define
+ // which can add any additional metadata the implementer wants and define
// a custom format for the message stream.
oneof artifact_type {
FileArtifactType file = 101;
diff --git a/doc/mgmt/gnmi/gnoi_system_hld.md b/doc/mgmt/gnmi/gnoi_system_hld.md
index 45e0134e68a..d730c4035af 100644
--- a/doc/mgmt/gnmi/gnoi_system_hld.md
+++ b/doc/mgmt/gnmi/gnoi_system_hld.md
@@ -102,7 +102,7 @@ message RebootRequest {
string message = 3;
// Optional sub-components to reboot.
repeated types.Path subcomponents = 4;
- // Force reboot if sanity checks fail. (ex. uncommited configuration)
+ // Force reboot if sanity checks fail. (ex. uncommitted configuration)
bool force = 5;
}
@@ -127,7 +127,7 @@ enum RebootMethod {
POWERUP = 7; // Apply power, no-op if power is already on.
}
-// A CancelRebootRequest requests the cancelation of any outstanding reboot
+// A CancelRebootRequest requests the cancellation of any outstanding reboot
// request.
message CancelRebootRequest {
string message = 1; // informational reason for the cancel
@@ -163,7 +163,7 @@ message RebootStatus {
string message = 2;
}
-// A TimeRequest requests the current time accodring to the target.
+// A TimeRequest requests the current time according to the target.
message TimeRequest {
}
diff --git a/doc/mgmt/gnmi/gnsi.md b/doc/mgmt/gnmi/gnsi.md
index 6f5d2734899..7d85e6636ae 100644
--- a/doc/mgmt/gnmi/gnsi.md
+++ b/doc/mgmt/gnmi/gnsi.md
@@ -65,7 +65,7 @@ Add the microservice for supporting gNSI APIs. Add related gNMI telemetry paths.
### Overview
-gRPC Network Security Interface is a set of microservices to provides a management layer for security credentials of multiple types. Each service shares a similiar design of `Rotate()` which takes in the new payload, creates a backup of the current state, and rolls back the state if it isn't finalized.
+gRPC Network Security Interface is a set of microservices to provides a management layer for security credentials of multiple types. Each service shares a similar design of `Rotate()` which takes in the new payload, creates a backup of the current state, and rolls back the state if it isn't finalized.
### Requirements
@@ -166,7 +166,7 @@ Pathz is policy based authorization for gNMI access that is tunable for read/wri
#### Credentialz
-Credentialz is for managing SSH and Console access. Changes are made through dbus calls to appropiate host service modules. The expected calls and behavior of the host service modules are defined in the next sections.
+Credentialz is for managing SSH and Console access. Changes are made through dbus calls to appropriate host service modules. The expected calls and behavior of the host service modules are defined in the next sections.
- Credentialz.RotateAccountCredentials()
- Modify users' keys, passwords, and certificates
diff --git a/doc/mgmt/gnmi/master_arbitration.md b/doc/mgmt/gnmi/master_arbitration.md
index b6db0cd569d..78d6728dbaa 100644
--- a/doc/mgmt/gnmi/master_arbitration.md
+++ b/doc/mgmt/gnmi/master_arbitration.md
@@ -66,7 +66,7 @@ All `Set` RPCs that uses a default role are arbitrated in the same group.
### Requirements
-Master Arbitration is a HA (high-availability) SDN-focused feature therefore it cannot be enabled by default. On the other hand, when it is required, it has to be enabled from the very moment the gNMI server starts. As an optional feature, Master Arbitration could be turned off when gNMI server restarted. And it should not impact the overall perfermance.
+Master Arbitration is a HA (high-availability) SDN-focused feature therefore it cannot be enabled by default. On the other hand, when it is required, it has to be enabled from the very moment the gNMI server starts. As an optional feature, Master Arbitration could be turned off when gNMI server restarted. And it should not impact the overall performance.
### Architecture Design
@@ -178,7 +178,7 @@ It should be noted that Master Arbitration only affects `SET` operations. Theref
The modification of the `SetRequest` has an impact on the gNMI management interface. In order to ensure serviceability and facilitate debugging, it will be necessary to include a logging message for Master Arbitration.
-As a disabled feature by default, a DEBUG level log message is needed when a client is seleced as master, i.e. `ReqFromMaster = True`. When gNMI server decides a non-master client, a DEBUG level log message should be generated as well. The message should include the `election_id`. Error level log message should be printed when a non-master clients try to send request to gNMI server, inidcating the `Permission Deny` error.
+As a disabled feature by default, a DEBUG level log message is needed when a client is selected as master, i.e. `ReqFromMaster = True`. When gNMI server decides a non-master client, a DEBUG level log message should be generated as well. The message should include the `election_id`. Error level log message should be printed when a non-master clients try to send request to gNMI server, indicating the `Permission Deny` error.
### SAI API
@@ -311,20 +311,20 @@ The main focus of the test is on the coverage of the new feature. The user cases
Mock one or more clients in the unit tests to test the feature. Here are the list of test cases in unit test:
* TestDisabledMasterArbitration
- * Single client - Expect always recieving request
- * Multiple clients - Expect recieving requests from all clients
+ * Single client - Expect always receiving request
+ * Multiple clients - Expect receiving requests from all clients
* TestEnabledMasterArbitrationWithoutProtoDefine
- * Single client - Expect always recieving request
- * Multiple clients - Expect recieving requests from all clients, as all clients with `EID = 0` but no comparsion happens.
+ * Single client - Expect always receiving request
+ * Multiple clients - Expect receiving requests from all clients, as all clients with `EID = 0` but no comparison happens.
* TestDisabledMasterArbitrationWithProtoDefine
- * Single client - Expect always recieving request
- * Multiple clients - Expect recieving requests from all clients
+ * Single client - Expect always receiving request
+ * Multiple clients - Expect receiving requests from all clients
* TestEnabledMasterArbitrationWithProtoDefine
- * Single client - Expect always recieving request
- * Multiple clients - Expect recieving requests from the client with the largest `EID`. As `EID` is guaranteed to be monotonically increasing, the last client will be used.
+ * Single client - Expect always receiving request
+ * Multiple clients - Expect receiving requests from the client with the largest `EID`. As `EID` is guaranteed to be monotonically increasing, the last client will be used.
* TestEnabledMasterArbitrationWithChangeOfMaster
- * Single client - Expect always recieving request
- * Multiple clients - Expect recieving requests from the client with the largest `EID` and requests from other clients will be rejected.
+ * Single client - Expect always receiving request
+ * Multiple clients - Expect receiving requests from the client with the largest `EID` and requests from other clients will be rejected.
* TestMasterArbitrationWhenSwitchRestart
* Single client - Expect client with `EID = 0`
* Multiple clients - Expect all clients with `EID = 0`.
diff --git a/doc/mgmt/gnmi/save_on_set.md b/doc/mgmt/gnmi/save_on_set.md
index 2651767a5b0..64847a40bd9 100644
--- a/doc/mgmt/gnmi/save_on_set.md
+++ b/doc/mgmt/gnmi/save_on_set.md
@@ -48,7 +48,7 @@ Add the option for enabling the SONiC gNMI implementation to save its in-memory
### Overview
-Having configuration be persistant across switch reboot is a useful feature that is not currently implemented by Sonic-Telemetry.
+Having configuration be persistent across switch reboot is a useful feature that is not currently implemented by Sonic-Telemetry.
The required behaviour is to save the configuration to a file that is used to populate the configuration database during the startup process every time the gNMI.Set() RPC call is performed.
diff --git a/doc/mgmt/redis_client_manager.md b/doc/mgmt/redis_client_manager.md
index da5e2f7510e..724390edf3b 100644
--- a/doc/mgmt/redis_client_manager.md
+++ b/doc/mgmt/redis_client_manager.md
@@ -64,7 +64,7 @@ This function is implemented using a cache of Redis Clients that are initialized
-When a Redis Client is requested through this new function, the Redis Client is taken from the cache and returned to the caller. Multiple callers can use a given Redis Client at a time and the number of connections in the pool will increase to satisfy simulatenous Redis operations through the same client. All of the connection pool management is handled by go-redis, with more details [here](https://pkg.go.dev/github.com/go-redis/redis/v8#Options). This process looks like this:
+When a Redis Client is requested through this new function, the Redis Client is taken from the cache and returned to the caller. Multiple callers can use a given Redis Client at a time and the number of connections in the pool will increase to satisfy simultaneous Redis operations through the same client. All of the connection pool management is handled by go-redis, with more details [here](https://pkg.go.dev/github.com/go-redis/redis/v8#Options). This process looks like this:
@@ -187,7 +187,7 @@ Unit tests are implemented to test RCM's functionality. Since callsites are upda
- TestConnectionPoolDisable
- Tests the command line flag that can be used to enable/disable Redis connection pools.
- TestNilRCM
- - Tests the scenario where RCM is nil or never intialized.
+ - Tests the scenario where RCM is nil or never initialized.
- TestRedisCounters
- Tests that the RCM counters are updated correctly given different scenarios.
- TestRedisClientManagerCounters
diff --git a/doc/mgmt/sonic_stretch_management_vrf_design.md b/doc/mgmt/sonic_stretch_management_vrf_design.md
index 31c0834fad1..0906a3081e9 100644
--- a/doc/mgmt/sonic_stretch_management_vrf_design.md
+++ b/doc/mgmt/sonic_stretch_management_vrf_design.md
@@ -40,7 +40,7 @@ IP packets arriving on the switch will be associated to a VRF, based on the inco
Note: Transit traffic will never be forwarded between default and management VRF and vice-versa.
### Originating On The Switch
-All switch-originated traffic will be based on the VRF on which the applications are running. By default all application will use the default routing table unless explictly mentioned to use management VRF. Applications like ping, traceroute has option to specify which interface (VRF) to use while sending packets out and hence they work on both default VRF & management VRF. The design approach for each application is explained in later sections.
+All switch-originated traffic will be based on the VRF on which the applications are running. By default all application will use the default routing table unless explicitly mentioned to use management VRF. Applications like ping, traceroute has option to specify which interface (VRF) to use while sending packets out and hence they work on both default VRF & management VRF. The design approach for each application is explained in later sections.
## Design
L3 Master Device (l3mdev) is based on L3 domains that correlate to a specific FIB table. Network interfaces are enslaved to an l3mdev device uniquely associating those interfaces with an L3 domain. Packets going through devices enslaved to an l3mdev device use the FIB table configured for the device for routing, forwarding and addressing decisions. The key here is the enslavement only affects L3 decisions.
@@ -99,7 +99,7 @@ When the "config vrf add mgmt" CLI command is executed, following sequence of th
(a) This service first does "ifdown --force eth0" where it will execute all the commands specified in the already existing "/etc/network/interfaces" file.
For example, it will execute the command "down ip route delete default via dev eth0 table default", which will delete the existing default route from the routing table "default".
Similarly, it deletes the route related to directly connected network that corresponds to the management IP address. Note that these rules are already existing even without management vrf implementation.
- (b) It then regenerates the management VRF specific /etc/network/interfaces file as per the requriement
+ (b) It then regenerates the management VRF specific /etc/network/interfaces file as per the requirement
(c) It then restarts the "networking" service (explained in next point) which will bring up the management VRF.
As part of management vrf implementation, "interfaces.j2" file has been modified to create the management vrf specific "/etc/network/interfaces" file. The generated file is given below for reference.
@@ -150,7 +150,7 @@ When the "config vrf del mgmt" CLI command is executed, following sequence of th
For example, it will execute the command "down ip route delete default via dev eth0 table 5000", which will delete the existing default route from the routing table "5000" that corresponds to management VRF.
Similarly, it deletes the route related to directly connected network that corresponds to the management IP address. Note that these rules are same as the rules that were already existing even without management VRF implementation; the only difference is the routing table name/ID.
It also deletes the CGROUP "l3mdev:mgmt" using the command "cgdelete -g l3mdev:mgmt".
- (b) It then regenerates the management VRF specific /etc/network/interfaces file as per the requriement
+ (b) It then regenerates the management VRF specific /etc/network/interfaces file as per the requirement
(c) It then restarts the "networking" service (explained in next point) which will bring up the the system without management VRF.
As part of management vrf implementation, "interfaces.j2" file has been modified to delete the management vrf specific interfaces using the "/etc/network/interfaces" file. The default "/etc/network/interfaces" file is given below for reference.
@@ -243,7 +243,7 @@ This section explains the behavior of each application on the default VRF and ma
#### Application Daemons In The Device
##### TCP Application Daemons
-Linux kernel has got the flag tcp_l3mdev_accept which is required for enabling the TCP applications to receive and process packets from both data VRF and management VRF. By default, this flag is already enabled. With this flag enabled, TCP is capable of accepting the incoming connections that internally binds the incoming interface to the connection. i.e. When connection request arrives via the front-panel ports, TCP accepts the connection via the front-panel port; when connect request arrives via the management port (eth0), it accepts via the management port. Example: sshd, ftpd, etc., No changes are required in these deamons to make them work on both management VRF and default VRF.
+Linux kernel has got the flag tcp_l3mdev_accept which is required for enabling the TCP applications to receive and process packets from both data VRF and management VRF. By default, this flag is already enabled. With this flag enabled, TCP is capable of accepting the incoming connections that internally binds the incoming interface to the connection. i.e. When connection request arrives via the front-panel ports, TCP accepts the connection via the front-panel port; when connect request arrives via the management port (eth0), it accepts via the management port. Example: sshd, ftpd, etc., No changes are required in these daemons to make them work on both management VRF and default VRF.
##### UDP Application Daemons
Linux 4.9 does not support `udp_l3mdev_accept`; corresponding patch is back ported to SONiC Linux 4.9. With this patch, UDP applications will be able to receive and process packets from both data VRF and management VRF. UDP being a connectionless protocol, these is no concept of accepting the connection through the same incoming port (VRF) and hence UDP applications will not be able to specify the interface through which the reply has to be sent. i.e. When UDP applications send a reply reply packet, there is no reference to the port in which the request packet had arrived. Hence the Linux stack will try to route this packet via default routing table, even if request packet had arrived via management port. Such UDP application daemon code needs to be modified to use the incoming port reference and use it for sending replies via the same VRF through which the request had arrived.
@@ -328,7 +328,7 @@ TACPLUS_SERVER address 10.11.55.41
2. snmp traps from device: netsnmp 5.7.3 Linux patch has VRF support for traps. Conifuguration file needs to specify VRF name. Above mentioned PRs handle the required changes.
#### NTP
-When managmenet VRF is enabled, NTP application is restarted in the mvrf context by doing the following changes.
+When management VRF is enabled, NTP application is restarted in the mvrf context by doing the following changes.
Debian contains the NTP package that has got the NTP initialization script file /etc/init.d/ntp that calls "start-stop-daemon" command which in turn starts the "ntpd" daemon as follows.
```
start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --startas $DAEMON -- -p $PIDFILE $NTPD_OPTS
@@ -339,7 +339,7 @@ cgexec -g l3mdev:mgmt start-stop-daemon --start --quiet --oknodo --pidfile $PIDF
```
Since this file "/etc/init.d/ntp" is part of the default NTP package from debian, this file is manually copied into sonic-buildimage (at files/image_config/ntp/ntp) and modified to handle the mvrf enable status. It is then copied into /etc/init.d/ntp along with this mvrf changes. Whenever a new version of NTP is added to SONiC, care must be taken to repeat this change as required.
-In addtion to this change, NTP has got linux commands like "ntpq" which communicates with "ntpd" using the loopback IP address 127.0.0.1.
+In addition to this change, NTP has got linux commands like "ntpq" which communicates with "ntpd" using the loopback IP address 127.0.0.1.
Hence, a dummy interface "lo-m" is created and enslaved into "mgmt" and configured with the IP address 127.0.0.1
These NTP changes are done as part of the pull request [PR3204](https://github.com/sonic-net/sonic-buildimage/pull/3204)
@@ -356,7 +356,7 @@ IP address changes or gateway changes are correctly reflected.
#### DHCP Relay
DHCP relay is expected to work via the default VRF.
-DHCP Relay shall receive the DHCP requests from servers via the front-panel ports and it will send it to DHCP server through front-panel ports. No code changes are reqiured.
+DHCP Relay shall receive the DHCP requests from servers via the front-panel ports and it will send it to DHCP server through front-panel ports. No code changes are required.
#### DNS
@@ -367,7 +367,7 @@ When such processes call DNS POSIX API like getaddrinfo, the sockets opened by t
Hence, no other code change is required to make the internal DNS calls to work.
#### Other Applications
-Applications like "apt-get", "ntp", "scp", "sftp", "tftp", "wget" are expected to work via both default VRF & management VRF when users connect from external device to the respective deamons running in the device.
+Applications like "apt-get", "ntp", "scp", "sftp", "tftp", "wget" are expected to work via both default VRF & management VRF when users connect from external device to the respective daemons running in the device.
When these applications are triggered from the device, they work through default VRF by default without any change.
To make them work through management VRF, use "cgexec -g l3mdev:mgmt" as prefix before the actual command.
@@ -393,7 +393,7 @@ For example, we will have to run two instances of lldp/ssh, one for Management a
### Conclusion: Use l3mdev instead of namespace
The Linux kernel has brought in the l3mdev primarily to provide the VRF solution in the L3 layer.
-Linux kernel upgrades are also targetted towards using the L3mdev solution for VRF.
+Linux kernel upgrades are also targeted towards using the L3mdev solution for VRF.
Industry also uses l3mdev as the solution for VRF.
Hence, it is decided to use l3mdev solution for supporting the VRF requirements.
The alternate solution that is based on "Namespace" (given above) has been ignored due to the reasons stated above.
diff --git a/doc/mpls/MPLS_hld.md b/doc/mpls/MPLS_hld.md
index 61bcbca5a71..d5bf529293e 100644
--- a/doc/mpls/MPLS_hld.md
+++ b/doc/mpls/MPLS_hld.md
@@ -308,7 +308,7 @@ New Netlink message next-hop accessors were added to retrieve attributes in a ne
##### IntfMgr
IntfMgr is an existing daemon in SWSS container that monitors operations in CONFIG_DB on INTERFACE, PORTCHANNEL_INTERFACE, and VLAN_INTERFACE tables.
-For MPLS, IntfMgr is modified to additionally process the "mpls" enable/disble attribute from the CONFIG_DB and propagate this attribute to APPL_DB.
+For MPLS, IntfMgr is modified to additionally process the "mpls" enable/disable attribute from the CONFIG_DB and propagate this attribute to APPL_DB.
###### Functions
The following are functions for IntfMgr:
```
@@ -616,7 +616,7 @@ A new SONiC CLI command is introduced to configure interfaces for MPLS.
config interface mpls add|remove
##### Show CLI Commands
-A new SONiC CLI command is introduced to display the current MPLS configuraiton for interfaces.
+A new SONiC CLI command is introduced to display the current MPLS configuration for interfaces.
# Show MPLS state per INTERFACE/PORT_CHANNEL_INTERFACE/VLAN_INTERFACE
show interface mpls []
diff --git a/doc/multi_asic/SONiC_multi_asic_hld.md b/doc/multi_asic/SONiC_multi_asic_hld.md
index 7587c576200..7cf92486cba 100644
--- a/doc/multi_asic/SONiC_multi_asic_hld.md
+++ b/doc/multi_asic/SONiC_multi_asic_hld.md
@@ -97,13 +97,13 @@ The interfaces for a given ASIC is linked to its corresponding namespace.
In a multi-ASIC system, very commonly the ASICs are physically connected in a clos fabric topology. With sonic container dockers running as separate namespaces for each ASIC in a multi-ASIC system, we can model and configure the system as if there is a spine-leaf network topology within the box.
-
+
A high level software architectural view for a multi-asic system with 6 ASIC is shown as follows:
-
+
@@ -205,7 +205,7 @@ This section provides design details for a Multi ASIC system with a single CPU.
To detect if the system is a Single or Multi ASIC at run-time, a new configuration file, **asic.conf** is added.
* The file ***asic.conf*** is present in the directory `/usr/share/sonic/device//`. It has the following details
* NUM_ASIC=n, where n is the number of asic's in this platform.
- * The device identifier is the pci device id of the ASIC. This is used to populate the "asic_id" field in DEVICE_METADATA of the config_db file for each namespace. The "asic_id" is passed as the SAI instance identifier during the creation of orchagent proces in each namespace.
+ * The device identifier is the pci device id of the ASIC. This is used to populate the "asic_id" field in DEVICE_METADATA of the config_db file for each namespace. The "asic_id" is passed as the SAI instance identifier during the creation of orchagent process in each namespace.
These entries are present for all the 'n' asic's.
Sample asic.conf
@@ -452,7 +452,7 @@ A new template file database_global.json.j2 is introduced which is used to gener
#### 2.4.4.1. Infrastructure changes
-The dbconnector classes present in the sonic-py-swsssdk submodule viz. SoncV2Connector, ConfigDBConnector is enhanced to accept the namespace parameter to connect to the DB in a particular namesapce. The dbconnector in the sonic-swsscommon submodule viz DBConnector too will be enhanced to accept the namespace parameter.
+The dbconnector classes present in the sonic-py-swsssdk submodule viz. SoncV2Connector, ConfigDBConnector is enhanced to accept the namespace parameter to connect to the DB in a particular namespace. The dbconnector in the sonic-swsscommon submodule viz DBConnector too will be enhanced to accept the namespace parameter.
Please refer [multi namespace db instance implementation document](https://github.com/sonic-net/SONiC/blob/master/doc/database/multi_namespace_db_instances.md) for more details.
### 2.4.5. Configuration CLIs
@@ -461,19 +461,19 @@ Please refer [multi namespace db instance implementation document](https://githu
* config save/load/reload : No additional namespace argument added to these commands. These commands perform the action using the list of config_db.json files either given by user as parameter or by using the default config_db files
/etc/sonic/config_db.json, /etc/sonic/config_db0.json, /etc/sonic/config_db1.json etc as there are number of asic/namespace needed in the platform.
- * config load_minigraph : No additional namespace argument added to this command. It parses the minigraph and populates the database instances present in different namesapces.
+ * config load_minigraph : No additional namespace argument added to this command. It parses the minigraph and populates the database instances present in different namespaces.
* config bgp : No additional namespace argument added to bgp commands. The bgp startup/shutdown all commands are applied on the external bgp sessions ( where BGP neighbors are external routers ). The commands like bgp
applies to either internal/external BGP sessions as per the user input.
* config interface : Added an optional argument to specify the namespace [ -n namespace ]. In Multi-ASIC devices the namespace could either be taken as a user input or if not provided will be derived based on the interface name.
* config vlan : Added an optional argument to specify the namespace [ -n namespace ]. In Multi-ASIC devices namespace parameter is mandatory for (add/del) of vlan and member interface.
- * config portchannel : Added an optional argument to specify the namespace [ -n namespace ]. In Multi-ASIC devices namesapce parameter is mandatory for (add/del) of portchannel and member interface.
+ * config portchannel : Added an optional argument to specify the namespace [ -n namespace ]. In Multi-ASIC devices namespace parameter is mandatory for (add/del) of portchannel and member interface.
### 2.4.6. Platform Services
The PMON container remains as a single instance service running in the linux host. The platform daemons viz psud, syseepromd, thermalctld, fancontrol updates tables viz. CHASSIS_INFO_TABLE, PSU_INFO_TABLE, EEPROM_TABLE, FAN_INFO_TABLE, TEMPER_INFO_TABLE which are in the _globalDB_ database container.
The ledd daemon will be updated to listen for change events from PORT tables in APP DB present in all namespaces.
-The xcvrd daemon will get/set the data from interface related tables viz. TRANSCEIVER_INFO_TABLE, TRANSCEIVER_DOM_SENSOR_TABLE, TRANSCEIVER_STATUS_TABLE present in database containers running in different namespaces. It will continue to have three threads viz. main, dom_sensor_update, sfp_state_update as is there currently, but will use the enhanced DB access API's from the sonic-swsscommon submodule which accepts the namespace parameter to connect and update the tables in the respective namesapce DB tables. The interface name will be used to dynamically derive the right namespace database instance.
+The xcvrd daemon will get/set the data from interface related tables viz. TRANSCEIVER_INFO_TABLE, TRANSCEIVER_DOM_SENSOR_TABLE, TRANSCEIVER_STATUS_TABLE present in database containers running in different namespaces. It will continue to have three threads viz. main, dom_sensor_update, sfp_state_update as is there currently, but will use the enhanced DB access API's from the sonic-swsscommon submodule which accepts the namespace parameter to connect and update the tables in the respective namespace DB tables. The interface name will be used to dynamically derive the right namespace database instance.
### 2.4.7. Monitoring/Troubleshooting
@@ -502,7 +502,7 @@ A new daemon will be added in BGP docker, which will populate STATE_DB with requ
There is also dependency on management interface related information. Currently, the Interfaces MIB has interface operational status information. This table currently shows operational status of management interface along with operational status of all front panel interfaces. SWSS updates the operational status in STATE_DB. As there is no swss running on the host namespace, this information will be retrieved from _/sys/class/net/**mgmt interface**/operstate._
-Below are the list of MIBs suppored by snmp_ax_impl.
+Below are the list of MIBs supported by snmp_ax_impl.
|OID | | Name | Data source |
|----|--|------|-------------|
@@ -529,7 +529,7 @@ There will be a single Telemetry service and telemetry docker for the multi asic
#### 2.4.7.3. LLDP
-LLDP service/docker in multi-asic platforms will be running in both host and asic namespaces. For host namesapce LLDP is running on Management interface and per-asic namespace LLDP is running on both Frontend and Backend interfaces. This enables visualizing internal links and internal devices information.
+LLDP service/docker in multi-asic platforms will be running in both host and asic namespaces. For host namespace LLDP is running on Management interface and per-asic namespace LLDP is running on both Frontend and Backend interfaces. This enables visualizing internal links and internal devices information.
#### 2.4.7.4. ACL
@@ -539,7 +539,7 @@ For Control ACL's:
- Iptables rules are currently programmed on the host as these rules are applied to traffic coming from management interface.
- Iptable rules will also be programmed in each namespace which are applied from the traffic from frontend ports
- Data and Everflow ACLs are programed in all front-end asic's only and are bound to corresponding frontend interfaces only. Backend asic's do not have any ACL's programmed and have no ACL rules bound to backend interfaces.
+ Data and Everflow ACLs are programmed in all front-end asic's only and are bound to corresponding frontend interfaces only. Backend asic's do not have any ACL's programmed and have no ACL rules bound to backend interfaces.
#### 2.4.7.5. Everflow
@@ -751,7 +751,7 @@ asic0: BGP router identifier 10.0.107.16, local AS number 65100 vrf-id 0
BGP table version 28012
asic1: BGP router identifier 10.0.107.19, local AS number 65100 vrf-id 0
BGP table version 10040
-Neighbhor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
+Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
------------ --- ----- --------- --------- -------- ----- ------ --------- -------------- --------------
10.10.192.53 4 64011 87404 91254 0 0 0 3d00h49m 6 11T0
10.10.192.55 4 64012 87396 91254 0 0 0 3d00h49m 6 12T0
@@ -780,7 +780,7 @@ asic1: BGP router identifier 10.0.107.19, local AS number 65100 vrf-id 0
BGP table version 13051
asic2: BGP router identifier 10.0.107.20, local AS number 65100 vrf-id 0
BGP table version 12977
-Neighbhor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
+Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
------------ --- ----- --------- --------- -------- ----- ------ --------- -------------- --------------
10.0.107.0 4 65100 6468 12038 0 0 0 3d00h32m 6564 ASIC2
10.0.107.1 4 65100 12038 6468 0 0 0 3d00h32m 6409 ASIC0
@@ -810,7 +810,7 @@ asic0: BGP router identifier 10.0.107.16, local AS number 65100 vrf-id 0
BGP table version 28012
RIB entries 13127, using 2415368 bytes of memory
Peers 4, using 83680 KiB of memory
-Neighbhor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
+Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
----------- --- ----- --------- --------- -------- ----- ------ --------- -------------- --------------
10.0.107.0 4 65100 6468 12038 0 0 0 3d00h35m 6564 ASIC1
10.106.0.1 4 65200 90278 99008 0 0 0 3d00h33m 6402 01T2
@@ -827,7 +827,7 @@ asic2: BGP router identifier 10.0.107.20, local AS number 65100 vrf-id 0
BGP table version 12967
RIB entries 13125, using 2415000 bytes of memory
Peers 4, using 83680 KiB of memory
-Neighbhor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
+Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
----------- --- ----- --------- --------- -------- ----- ------ --------- -------------- --------------
10.0.107.1 4 65100 12038 6468 0 0 0 3d00h36m 6409 ASIC0
10.0.107.13 4 65100 45 6464 0 0 0 3d00h36m 74 ASIC1
@@ -841,7 +841,7 @@ asic1: BGP router identifier 10.0.107.19, local AS number 65100 vrf-id 0
BGP table version 10040
RIB entries 13127, using 2415368 bytes of memory
Peers 12, using 251040 KiB of memory
-Neighbhor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
+Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd NeighborName
------------ --- ----- --------- --------- -------- ----- ------ --------- -------------- --------------
10.0.107.12 4 65100 6464 45 0 0 0 3d00h37m 6564 ASIC1
10.10.192.53 4 64011 87112 90962 0 0 0 3d00h35m 6 11T0
diff --git a/doc/nat/nat_design_spec.md b/doc/nat/nat_design_spec.md
index fa53b76bdd5..6bc96f7c39c 100644
--- a/doc/nat/nat_design_spec.md
+++ b/doc/nat/nat_design_spec.md
@@ -1522,7 +1522,7 @@ The Unit test case one-liners are as below:
| 19 | Verify that the NAT zone configuration is propagated to hardware. |
| 20 | Verify the outbound NAT translations to be working with traffic on VLAN or Ethernet or Port Channel L3 interfaces. |
| 21 | Verify that the dynamic NAPT translations are applied only on the traffic permitted by the ACL in the binding and not applied on the traffic that are 'do_no_nat'. |
-| 22 | Verify that the static NAPT entries are successfuly created in CONFIG_DB. |
+| 22 | Verify that the static NAPT entries are successfully created in CONFIG_DB. |
| 23 | Verify that the NAT pool config and the ACL association of the pool are configured and added to CONFIG_DB. |
| 24 | Verify that the static twice NAT/NAPT entries are successfully created in the APP_DB. |
| 25 | Verify that the traffic flows are double NAT'ted for the twice NAT/NAPT entries. |
@@ -1535,7 +1535,7 @@ The Unit test case one-liners are as below:
| 32 | Verify that the statistics are cleared on issuing the 'sonic-clear nat statistics' command. |
| 33 | Stop NAT docker and verify that any new dynamic NAT/NAPT entries are no longer added to hardware. |
| 34 | Start NAT docker and verify that the static NAT entries from CONFIG_DB are added in the kernel, APP_DB, ASIC_DB and any new dynamic entries are added to hardware. |
-| 35 | Verify that the traffic flows that are NAT translated are not affected during warm restart. Zero packet loss and successful reconcilation. |
+| 35 | Verify that the traffic flows that are NAT translated are not affected during warm restart. Zero packet loss and successful reconciliation. |
| 36 | Verify that the dynamic NAT translations are restored to APP_DB and the kernel after warm reboot. |
| 37 | Send up to 1024 outbound traffic flows that trigger creation of 1024 dynamic NAT entries. |
| 38 | Send more than 1024 outbound traffic flows and check that the NAT entry creations beyond 1024 entries are not created. |
diff --git a/doc/ntp/migration-to-chrony.md b/doc/ntp/migration-to-chrony.md
index 71ae493a08c..7d10db09c73 100644
--- a/doc/ntp/migration-to-chrony.md
+++ b/doc/ntp/migration-to-chrony.md
@@ -190,7 +190,7 @@ options that are available. The major ones of note are:
chrony doesn't quite have that. This is partly because the configuration
control for chrony is on a different port entirely (UDP port 323 instead of
UDP port 123), this making it easier to be firewalled off and/or configured
- separtely. In addition, chrony will default to using a client-server
+ separately. In addition, chrony will default to using a client-server
relationship instead of symmetric relationship (where both sides will sync
time with each other), unless the `peer` keyword is used instead of `server`.
* Chrony also allows storing the NTP servers in a separate file, making it
@@ -214,7 +214,7 @@ more NTP servers. If Monit sees that if the time is not synchronized for 3
minutes, then a message will be printed every 5 minutes saying that the time is
not synchronized.
-Sample messsage:
+Sample message:
```
2024 Nov 7 01:36:00.154986 vlab-01 ERR monit[735]: 'ntp' status failed (1) -- NTP is not synchronized with servers
diff --git a/doc/ntp/ntp-design.md b/doc/ntp/ntp-design.md
index d7c3f63b82f..c7ddef51c6b 100644
--- a/doc/ntp/ntp-design.md
+++ b/doc/ntp/ntp-design.md
@@ -399,7 +399,7 @@ To configure the feature we are going to use three Config DB tables:
`NTP` table is used to store NTP global configuration.
-`NTP_SERVER` table contains configured remote NTP servers and theis approprite configuration.
+`NTP_SERVER` table contains configured remote NTP servers and this appropriate configuration.
`NTP_KEY` table holds NTP authentication keys inventory.
- Keys values must be `base64` encrypted before writing to DB.
@@ -725,7 +725,7 @@ _SRV_OPTS_:
1. `-t|--type` - NTP server association type: `enum: server, pool`
2. `-k|--key` - NTP authentication key ID: `integer: 1-65535`
3. `-v|--version` - NTP protocol version `integer: 3-4`
-4. `-a|--aggressive` - NTP enable aggresive polling
+4. `-a|--aggressive` - NTP enable aggressive polling
_KEY_OPTS_:
1. `-t|--type` - NTP key type: `enum: md5, sha1`
diff --git a/doc/nvgre_tunnel/nvgre_tunnel.md b/doc/nvgre_tunnel/nvgre_tunnel.md
index 390845b88a2..b7d81d0304f 100755
--- a/doc/nvgre_tunnel/nvgre_tunnel.md
+++ b/doc/nvgre_tunnel/nvgre_tunnel.md
@@ -134,7 +134,7 @@ The following orchestration agents will be added or modified. The flow diagrams
The following sub-modules will be modified:
* [sonic-swss](https://github.com/sonic-net/sonic-swss) - will be extended with the new orchestration agent for NVGRE.
* [sonic-swss-common](https://github.com/sonic-net/sonic-swss-common) - will be extended with the new tables for ConfigDB.
-* [sonic-utilities](https://github.com/sonic-net/sonic-utilities) - will be extened with the new CLI.
+* [sonic-utilities](https://github.com/sonic-net/sonic-utilities) - will be extended with the new CLI.
#### Sequence diagrams
diff --git a/doc/passw_hardening/hld_password_hardening.md b/doc/passw_hardening/hld_password_hardening.md
index 477f9e271b1..969b6114e75 100644
--- a/doc/passw_hardening/hld_password_hardening.md
+++ b/doc/passw_hardening/hld_password_hardening.md
@@ -208,7 +208,7 @@ As a result of the changes above, new users will have an expiration time of 1 da
root@arc-switch1004:/home/admin# su test_user1
Warning: your password will expire in 1 day
-Regaring the policy when expiration time end (PASS_MAX_DAYS):
+Regarding the policy when expiration time end (PASS_MAX_DAYS):
The maximum number of days a password may be used. If the
password is older than this, a password change will be
diff --git a/doc/path_tracing/path_tracing_midpoint.md b/doc/path_tracing/path_tracing_midpoint.md
index 84b3992d1e9..8e48824283c 100755
--- a/doc/path_tracing/path_tracing_midpoint.md
+++ b/doc/path_tracing/path_tracing_midpoint.md
@@ -77,7 +77,7 @@ Each PT Midpoint node on the packet path records a tiny piece of information kno
The Midpoint Compressed Data (MCD) contains the outgoing interface ID, outgoing (truncated) timestamp, and the load of the outgoing interface.
-Every interface of the PT Midpoint is assigned an interface ID and timestamp template. The timestamp template defines how to trunacte the timestamp (i.e., which bits of the timestamp are selected).
+Every interface of the PT Midpoint is assigned an interface ID and timestamp template. The timestamp template defines how to truncate the timestamp (i.e., which bits of the timestamp are selected).
In this document, we provide the SONiC High Level Design (HLD) to program the Path Tracing Interface ID and timestamp template.
diff --git a/doc/pcie-mon/pcie-monitoring-services-hld.md b/doc/pcie-mon/pcie-monitoring-services-hld.md
index 7954e6e6752..0c8344d2392 100644
--- a/doc/pcie-mon/pcie-monitoring-services-hld.md
+++ b/doc/pcie-mon/pcie-monitoring-services-hld.md
@@ -38,7 +38,7 @@ For the convenience of implementation and reduce the time consuming, pcie-check.
1. `pcieutil` should get the platform specific PCIe device information and monitor the PCIe device and bus status with PcieUtil.get_pcie_check.
-2. `PcieUtil` will provide APIs `load_config_file`, `get_pcie_device` and `get_pcie_check` to get the expected PCIe device list and informations, to get the current PCIe device information, and check if any PCIe device is missing or if there is any PCIe bus error.
+2. `PcieUtil` will provide APIs `load_config_file`, `get_pcie_device` and `get_pcie_check` to get the expected PCIe device list and information, to get the current PCIe device information, and check if any PCIe device is missing or if there is any PCIe bus error.
@@ -93,7 +93,7 @@ PcieUtil calls this API to check the PCIe device status, following example code
### 1.4 PCIe Check Service `pcie-check.service` flow ###
-pcie-check.service will be started by systemd during boot up and it will spawn a thread to check PCIe device status and perform the rescan pci devices if there is any missing devices after rc.local.service is completed and it will update the state db with pcie device satus after the `pcieutil pcie-chek` call so that the dependent services/container or kernel driver can be started or stopped based on the status.
+pcie-check.service will be started by systemd during boot up and it will spawn a thread to check PCIe device status and perform the rescan pci devices if there is any missing devices after rc.local.service is completed and it will update the state db with pcie device status after the `pcieutil pcie-chek` call so that the dependent services/container or kernel driver can be started or stopped based on the status.
Detailed flow as showed in below chart:
@@ -424,6 +424,6 @@ root@sonic:/home/admin#
< TBA >
## Open Questions ##
-1. Current PcieUtil is limited to check the PCIe device availablility based on the configuration.
+1. Current PcieUtil is limited to check the PCIe device availability based on the configuration.
Can we also add the PCIe communication error status check using AER detection into get_pcie_check() api or with a separate api?
some plugins like, say, collectd (https://wiki.opnfv.org/display/fastpath/PCIe+Advanced+Error+Reporting+Plugin)
diff --git a/doc/pcieinfo_design.md b/doc/pcieinfo_design.md
index 5ff2df0a0ce..2d53bbc474c 100644
--- a/doc/pcieinfo_design.md
+++ b/doc/pcieinfo_design.md
@@ -4,7 +4,7 @@ Add a PCIe Diag tool for SONiC. This tool including three commands
show platform pcieinfo -----> Show current device PCIe info
show platform pcieinfo -c -----> Check whether the PCIe info is correct
- pcieutil pcie_generate -----> Generate an PCIe info congfig file
+ pcieutil pcie_generate -----> Generate an PCIe info config file
## Implementation
### show utility update
@@ -48,9 +48,9 @@ Function: This file is used to fulfill the main interfaces including functions
**Config file**
-Location: `device/Platofrm/plugins/pcie.yaml`
+Location: `device/Platform/plugins/pcie.yaml`
-Function: This file is used to as a standard to distinguish the device PCIe info. for different platform, config file will locate in differnet path
+Function: This file is used to as a standard to distinguish the device PCIe info. for different platform, config file will locate in different path
***Format***
diff --git a/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md b/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md
index 7cd2a024561..3406cf47129 100644
--- a/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md
+++ b/doc/pfc_asym/PFC_Asymmetric_Test_HLD.md
@@ -96,7 +96,7 @@ Preparation before test cases run will be executed in the following pytest fixtu
To simulate that neighbors are overloaded (send many PFC frames) there is used PFC packets generator which is running on Fanout switch.
File location - ```roles/test/files/helpers/pfc_gen.py```
-Currnet fixture deploys ```roles/test/files/helpers/pfc_gen.py``` to the fanout host.
+Current fixture deploys ```roles/test/files/helpers/pfc_gen.py``` to the fanout host.
This step can be different for different platforms. Below there is description how it works for Mellanox and Arista cases, also how to add support of another platform type.
#### Notes
@@ -126,7 +126,7 @@ Copy "roles/test/files/helpers/pfc_gen.py" to "/mnt/flash" directory
Tests currently support deployment of arista fanout switches, **to support other platforms:**
1. Add platform specific logic to deploy pfc packet generator automatically in ```deploy_pfc_gen``` pytest fixture.
-Or manualy deploy ```roles/test/files/helpers/pfc_gen.py``` and ensure the file is available on fanout switch.
+Or manually deploy ```roles/test/files/helpers/pfc_gen.py``` and ensure the file is available on fanout switch.
2. Create ```pfc_storm_[sku].j2``` and ```pfc_storm_stop_[sku].j2``` under ```ansible/roles/test/templates/```
to trigger pfc storm **start/stop** action.
@@ -318,7 +318,7 @@ setup
#### Test steps
- Setup:
- Start ARP responder
- - Limit maximum bandwith rate on the destination port by setting "1" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
+ - Limit maximum bandwidth rate on the destination port by setting "1" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
- Clear all counters for all ports
- Get lossless priorities
@@ -332,7 +332,7 @@ setup
- Verify that PFC frames are not generated for lossy priorities
- Teardown:
- - Restore maximum bandwith rate on the destination port by setting "0" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
+ - Restore maximum bandwidth rate on the destination port by setting "0" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
- Stop ARP responder
### Test case # 2 – Asymmetric PFC Off RX pause frames
@@ -372,14 +372,14 @@ setup, enable_pfc_asym
#### Test steps
- Setup:
- Start ARP responder
- - Limit maximum bandwith rate on the destination port by setting "1" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
+ - Limit maximum bandwidth rate on the destination port by setting "1" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
- As SAI attributes stores PFC values like a bit vector, calculate bitmask for each PFC mode according to configured "lossless" priorities to have possibility to check that asymmetric PFC configuration for RX and TX queues was applied correctly for configured PFC mode:
- Calculate bitmask for the PFC value
- Calculate bitmask for the asymmetric PFC Tx value
- Calculate bitmask for the asymmetric PFC Rx value
-- Verify asymetric PFC mode is enabled on each server port
+- Verify asymmetric PFC mode is enabled on each server port
- Get asymmetric PFC Rx value for all server ports
- Verify asymmetric PFC Rx value for each server port
- Get asymmetric PFC Tx value for all server ports
@@ -400,12 +400,12 @@ setup, enable_pfc_asym
- Verify PFC value is restored to default
- Teardown:
- - Restore maximum bandwith rate on the destination port by setting "0" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
+ - Restore maximum bandwidth rate on the destination port by setting "0" into SAI port attribute SAI_PORT_ATTR_QOS_SCHEDULER_PROFILE_ID
- Stop ARP responder
### Test case # 4 – Asymmetric PFC On Rx pause frames on all priorities
#### Test objective
-Asymmetric PFC is enabled. Verify that while receiving PFC frames DUT handle PFC frames on all priorities when asymetric mode is enabled
+Asymmetric PFC is enabled. Verify that while receiving PFC frames DUT handle PFC frames on all priorities when asymmetric mode is enabled
#### Used fixtures
setup, pfc_storm_runner, enable_pfc_asym
diff --git a/doc/pic/hld_fpmsyncd.md b/doc/pic/hld_fpmsyncd.md
index 523918caf2f..954ed3de9d8 100644
--- a/doc/pic/hld_fpmsyncd.md
+++ b/doc/pic/hld_fpmsyncd.md
@@ -37,7 +37,7 @@
| Rev | Date | Author | Change Description |
| :---: | :----------: | :------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0.1 | Jul 14, 2023 | Kanji Nakano, Kentaro Ebisawa, Hitoshi Irino (NTT) | Initial version |
-| 0.2 | Jul 30, 2023 | Kentaro Ebisawa (NTT) | Remove description about VRF which is not nessesary for NHG. Add High Level Architecture diagram. Add note related to libnl, Routing WG. Fix typo and improve explanations. |
+| 0.2 | Jul 30, 2023 | Kentaro Ebisawa (NTT) | Remove description about VRF which is not necessary for NHG. Add High Level Architecture diagram. Add note related to libnl, Routing WG. Fix typo and improve explanations. |
| 0.3 | Sep 18, 2023 | Kentaro Ebisawa (NTT) | Update based on discussion at Routing WG on Sep 14th (Scope, Warmboot/Fastboot, CONFIG_DB) |
| 0.4 | Sep 24, 2023 | Kentaro Ebisawa (NTT) | Add feature enable/disable design and CLI. Update test plan. |
| 0.5 | Nov 10, 2023 | Kanji Nakano (NTT) | Update feature enable/disable design and CLI. Update test plan. |
@@ -321,7 +321,7 @@ System reboot is required after enabling/disabling this feature to make sure rou
#### Configuration data flow
-Diagram shows how `zebra.conf` is genereated from CONFIG_DB data.
+Diagram shows how `zebra.conf` is generated from CONFIG_DB data.
##### Figure: Configuration data flow
@@ -537,7 +537,7 @@ This feature extends the existing NEXT_HOP_GROUP_TABLE, to store next hop group
ifname = *INTF_TABLE.key, ; zero or more separated
by “,” (zero indicates no interface)
nexthop_group = NEXT_HOP_GROUP_TABLE:key, ; index within the
- NEXT_HOP_GROUP_TABLE seperated by "," used
+ NEXT_HOP_GROUP_TABLE separated by "," used
for recursice/ecmp routes. (New field. When this field
is present, other fields will not be present)
@@ -730,7 +730,7 @@ We should review this PR (and any other related patches if found) so difference
#### Further performance improvements
-Extention to fpmsyncd described in this HLD will only change how `fpmsyncd` will handle `RTM_NEWNEXTHOP` and `RTM_DELNEXTHOP`.
+Extension to fpmsyncd described in this HLD will only change how `fpmsyncd` will handle `RTM_NEWNEXTHOP` and `RTM_DELNEXTHOP`.
Further study is required for more fundamental improvements, e.g. how zebra handles NextHop Groups in scale, communication channel between zebra and fpmsyncd, improvements in FRR like BGP PIC support etc.
@@ -753,7 +753,7 @@ There is a `sysctl` option `net.ipv4.nexthop_compat_mode nexthop_compat_mode` wh
This option is not changed as part this HLD to avoid unexpected impact to the existing behavior.
-One should carefully study the impact of this change before chainging this option.
+One should carefully study the impact of this change before changing this option.
#### Warmboot/Fastboot support
diff --git a/doc/pins/p4rt_app_hld.md b/doc/pins/p4rt_app_hld.md
index a1da70af655..6898c36250b 100644
--- a/doc/pins/p4rt_app_hld.md
+++ b/doc/pins/p4rt_app_hld.md
@@ -153,7 +153,7 @@ OrchAgent added a new orchestrator HashOrch to take care of programming the hash
P4RT application needs a response status for every request (success and failure) that is sent southwards to the OrchAgent. This ensures the external client making the request is aware of the status and can respond appropriately.
-At a high level, syncd operates in synchronous mode and OrchAgent relays the hardware status of the operation back to P4RT application via a separate notification channel and writes all successful responses into the APPL_STATE_DB. This abstraction differs from the existing STATE_DB which does not provide an application level response. P4RT application uses the APPL_STATE_DB to restore the entry in APPL_DB when a particular request fails. More details on the response path design is captured in the AppDb Shema HLD.
+At a high level, syncd operates in synchronous mode and OrchAgent relays the hardware status of the operation back to P4RT application via a separate notification channel and writes all successful responses into the APPL_STATE_DB. This abstraction differs from the existing STATE_DB which does not provide an application level response. P4RT application uses the APPL_STATE_DB to restore the entry in APPL_DB when a particular request fails. More details on the response path design is captured in the AppDb Schema HLD.
## APPL DB Schema High-Level Design
diff --git a/doc/platform/brcm_pdk_pddf.md b/doc/platform/brcm_pdk_pddf.md
index ec73f17942f..3c4400a0715 100644
--- a/doc/platform/brcm_pdk_pddf.md
+++ b/doc/platform/brcm_pdk_pddf.md
@@ -725,7 +725,7 @@ fan_fault
where idx represents the Fan index [1..32]
```
-Since PDDF has been changed to support platform 2.0 APIs, general design considers all the FANs inside a fantray as seperate FANs. If a fantray consist of two fans, front and rear, JSON object for FAN not only provides the access details for the front fan but also for the rear fan.
+Since PDDF has been changed to support platform 2.0 APIs, general design considers all the FANs inside a fantray as separate FANs. If a fantray consist of two fans, front and rear, JSON object for FAN not only provides the access details for the front fan but also for the rear fan.
##### 3.4.4.2 FAN JSON Design
FAN JSON is structured to include the access-data for all the supported SysFS attributes.
@@ -1108,7 +1108,7 @@ The SysFS paths should be given as per the PDDF I2C topology description and the
FPGA can be programmed as a I2C master controller. Some platforms use a FPGAPCIe card to control I2C devices and the communication with the CPU is by PCIe interface. PDDF supports a FPGAPCIe card by providing the following modules:
* FPGAPCIe Data Module:
- - Mange access data defined in JSON via SysFS interface
+ - Manage access data defined in JSON via SysFS interface
- Populate data and trigger FPGAPCIe instantiation
* FPGAPCIe Driver Module:
- PCIe device instantiation
@@ -1122,7 +1122,7 @@ connected FPGA, vendors need to provide the FPGA driver.
##### 3.4.12.1 FPGAPCIe JSON Design
-FPGAPCIe JSON object follows PDDF I2C topology JSON object design concept. FPGAPCIE object is under i2c keyword becuase it is programmed as I2c buses to control I2C client devices.
+FPGAPCIe JSON object follows PDDF I2C topology JSON object design concept. FPGAPCIE object is under i2c keyword because it is programmed as I2c buses to control I2C client devices.
```
@@ -1616,7 +1616,7 @@ If this field exists, the device name is displayed using this field. Otherwise,
ipmitool and ipmiapi are two methods of getting ipmi data. ipmitool uses ipmitool command to get data from BMC while ipmiapi will use kernel ipmi interfaces to retrieve the data. ipmiapi will be implemented in the future.
> **attr_name**:
-The PDDF BMC JSON design has the pre-defined list of the attribute names which is platform independent. IPMI is an standardized interface specification, but the naming convention of ipmitool output is vendor specific. The pre-defined attribue name list provides the ability to use generic PDDF generic platform APIs to retrieve information for all platforms.
+The PDDF BMC JSON design has the pre-defined list of the attribute names which is platform independent. IPMI is an standardized interface specification, but the naming convention of ipmitool output is vendor specific. The pre-defined attribute name list provides the ability to use generic PDDF generic platform APIs to retrieve information for all platforms.
> **bmc_cmd**:
There are two types of cmds: raw ipmi request and non raw ipmi request. The list of available ipmitool commands can be found by
@@ -1857,7 +1857,7 @@ Example,
#### 3.7.3 LED Class
-There is no generic LED API class defined in PDDF. LED APIs related to a component has been made part of thats component's platform API class. System LED APIs are made part of PddfChassis class.
+There is no generic LED API class defined in PDDF. LED APIs related to a component has been made part of that component's platform API class. System LED APIs are made part of PddfChassis class.
```
class PddfChassis(ChassisBase):
def set_system_led(self, device_name, color):
@@ -2134,7 +2134,7 @@ root@sonic:/home/admin#
-> NOTE: Above output differs from the ouput in PDDF v1.0. This is because of the fact that FAN numbering scheme changed due to introduction of 2.0 platform APIs. Rear fans are now considered separate fans. In above output,
+> NOTE: Above output differs from the output in PDDF v1.0. This is because of the fact that FAN numbering scheme changed due to introduction of 2.0 platform APIs. Rear fans are now considered separate fans. In above output,
> Fantray1_1: Front fan of frantray1
> Fantray1_2: Rear fan of fantray1
@@ -2321,19 +2321,19 @@ S3IP sysfs specification defines a unified interface to access peripheral hardwa
- S3IP sysfs should be generated and could be removed on requirement
- Though S3IP can be clubbed with PDDF, PDDF should be independent of the S3IP
-- If any attribute which cannot be read should have a value of 'NA' i.e. tools should not fail due to non existance of the attribute
+- If any attribute which cannot be read should have a value of 'NA' i.e. tools should not fail due to non existence of the attribute
- S3IP sysfs should be able to work with the existing PDDF common driver sysfs
- PDDF common driver attributes should be expanded, if required, to cover the left out attributes from S3IP specifications
### 7.2 Implementation Details
-The S3IP specifications and framework are defined [here](https://github.com/sonic-net/SONiC/pull/1068). Both vendors and users are required to follow the S3IP spec. The platform vendors need to provide the implementation of the set/get attribute functions for the platforms which use S3IP sysfs framework. The attributes for each component are defined in the specificaitons. This effort is to combine the S3IP spec and PDDF framework. In other words, the platform which are using PDDF would be S3IP compliant too after this support is added.
+The S3IP specifications and framework are defined [here](https://github.com/sonic-net/SONiC/pull/1068). Both vendors and users are required to follow the S3IP spec. The platform vendors need to provide the implementation of the set/get attribute functions for the platforms which use S3IP sysfs framework. The attributes for each component are defined in the specifications. This effort is to combine the S3IP spec and PDDF framework. In other words, the platform which are using PDDF would be S3IP compliant too after this support is added.
#### 7.2.1 PDDF and S3IP SysFS
PDDF implements common kernel drivers for various components. These common drivers exposes a fixed set of sysfs attributes as per the HW support and current SONiC API requirements. Complying to S3IP spec requires the mapping of S3IP component attributes to PDDF exposed sysfs attributes and might even require adding new attributes to PDDF common driver code. Hence, S3IP spec sysfs attributes are divided into the following categories.
- - Platform Info Attributes: This includes the fixed information pertaining to the platform in entirity or any component. There is no need of reading this information from the component in run time. Further, these values will not change in the course of System running the SONiC image. Below are few examples of static info attributes.
+ - Platform Info Attributes: This includes the fixed information pertaining to the platform in entirety or any component. There is no need of reading this information from the component in run time. Further, these values will not change in the course of System running the SONiC image. Below are few examples of static info attributes.
- /sys_switch/temp_sensor/number, /sys_switch/vol_sensor/number, /sys_switch/curr_sensor/number etc.
@@ -2355,7 +2355,7 @@ PDDF implements common kernel drivers for various components. These common drive
|-|-|-|-|
|/sys_switch/fan/fan[n]/status |RO| enum| Fan states are defined as follows:
0: not present
1: present and normal
2: present and abnormal
- - This is a combination of 'presence' and 'running_status' informations of a fan unit. In SONiC we can handle this in the platform APIs but S3IP compels to performs this processing inside the kernel modules. Hence if ODM extends the PDDF driver and provide the kernel implementation of such sysfs, we can create the mapping. Otherwise we will map it to 'NA'.
+ - This is a combination of 'presence' and 'running_status' information of a fan unit. In SONiC we can handle this in the platform APIs but S3IP compels to performs this processing inside the kernel modules. Hence if ODM extends the PDDF driver and provide the kernel implementation of such sysfs, we can create the mapping. Otherwise we will map it to 'NA'.
#### 7.2.2 S3IP SysFS Creation and Mapping
@@ -2394,11 +2394,11 @@ If the S3IP sysfs is required on a PDDF platform, it can be represented using th
...
```
-This pddf-s3ip service would create the sysfs as per the standards. It will also take care of linking the appropriate PDDF sysfs with the corrosponding S3IP sysfs.
+This pddf-s3ip service would create the sysfs as per the standards. It will also take care of linking the appropriate PDDF sysfs with the corresponding S3IP sysfs.
In case the platform does not support some attributes present in the S3IP spec, 'NA' will be written to the attribute file so that the application does not fail.
-Once this is done, users can run their S3IP compliant applicaitons and test scripts on the platform.
+Once this is done, users can run their S3IP compliant applications and test scripts on the platform.
#### 7.2.3 Adding S3IP Support for a Platform
diff --git a/doc/platform/common_config.md b/doc/platform/common_config.md
index 0868b712fb3..3b570e7bbe0 100644
--- a/doc/platform/common_config.md
+++ b/doc/platform/common_config.md
@@ -71,7 +71,7 @@ The design change for syncd_init_common.sh is targeted on the config_syncd_bcm()
In the updated 0.2 version, the script will check the platform specific config file. If it is yml based, it will merge common broadcom-sonic-{$chip_name}.config.bcm file with the existing platform specific config.yml file.
-In order to support common config overwriting the platform config feature in updated version 0.2. We propose a option for supporting properties of common config overwriting to the Platform config. The properties of common config in the High Inheritance Precedence section have the high priority than the platform specific config that will merge and overwrite the platform config. However, the properties of common config in the Low Inheritance Precedence section have the low priority than the platofrm specific config that will not merge and overwrite to the platform config if duplication properties present. As the following example, the properties of common config in the High Inheritance Precedence section will overwirte the platform specifc config during the merged process.However, the properties in the Low Inheritance Precedence section will not.
+In order to support common config overwriting the platform config feature in updated version 0.2. We propose a option for supporting properties of common config overwriting to the Platform config. The properties of common config in the High Inheritance Precedence section have the high priority than the platform specific config that will merge and overwrite the platform config. However, the properties of common config in the Low Inheritance Precedence section have the low priority than the platform specific config that will not merge and overwrite to the platform config if duplication properties present. As the following example, the properties of common config in the High Inheritance Precedence section will overwrite the platform specific config during the merged process.However, the properties in the Low Inheritance Precedence section will not.
```
/device/broadcom/x86_64-broadcom_common/x86_64-broadcom_b27/broadcom-sonic-td3.config.bcm
@@ -110,7 +110,7 @@ Nov 3 09:19:25.373964 2020 sonic INFO syncd#supervisord: syncd Merging
/tmp/td3-ix8a-bwde-48x25G+8x100G.config.bcm
```
### 4.2 Debug logs
-The finial config.bcm or config.yml and sai.profile will copy to the shared folder /var/run/sswsyncd/ in the syncd docker for 'show tech' debugging purpose. Developer can check the final config.bcm or conifg.yml file for debugging from the show tech dump /sai/xxx.config.bcm.
+The final config.bcm or config.yml and sai.profile will copy to the shared folder /var/run/sswsyncd/ in the syncd docker for 'show tech' debugging purpose. Developer can check the final config.bcm or config.yml file for debugging from the show tech dump /sai/xxx.config.bcm.
### Examples:
- Issue 'show tech'
diff --git a/doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md b/doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md
index 3e30e54b27b..4a2cf576d96 100644
--- a/doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md
+++ b/doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md
@@ -2227,7 +2227,7 @@ The `DomInfoUpdateTask` thread is responsible for updating the dynamic diagnosti
2. **Link change event:**
- Only the **flag-related diagnostic information** is updated for a port when a link change event is detected by the `DomInfoUpdateTask` thread. Further details on the tables updated during a link change event are provided in the `Diagnostic Information Update During Link Change Event` section.
- Updating flag information during a link change event ensures that the flag change time is captured in a timely manner. The periodic update can take more time to update the diagnostic information since it reads the diagnostic information for all the ports in a sequential manner.
- - The `DomInfoUpdateTask` thread may fail to update flag metadata and flag status if there are mutiple link change events happening in a short period of time. Please refer to the Non-goals section for more details.
+ - The `DomInfoUpdateTask` thread may fail to update flag metadata and flag status if there are multiple link change events happening in a short period of time. Please refer to the Non-goals section for more details.
- Since the flag registers are clear-on-read latched values, the `DomInfoUpdateTask` thread will require two reads to update the flag value, last clear time, and change count once the flagged condition is no longer present. Hence, it is expected that the flag status change in the database will be delayed by two update cycles when the flagged condition is no longer present on the module. Please refer to the Non-goals section for more details.
#### 5.2.1 High-Level Steps for Updating Dynamic Diagnostic Information
@@ -2489,7 +2489,7 @@ Specifically, the `TRANSCEIVER_STATUS` table contains the `diagnostics_update_in
#### Calculation of `diagnostics_update_interval`
-Since diagnostic monitoring is a frequent event, retrieving the average diagnostic interval would require the `DomInfoUpdateTask` to maintain a large cache of last update times for every poll. To reduce the overhead of maintaining such a large cache, we use the Exponentially Weighted Moving Average (EWMA) to calculate the `diagnostics_update_interval`. This approach provides a smooth and responsive average of the update intervals, allowing us to store a single `diagnostics_update_interval` and retrieve the average diagnostic update interval efficiently. An alpha value of 0.1 is used for the EWMA calculation to provide a smooth average while still being responsive to changes in the udpate intervals.
+Since diagnostic monitoring is a frequent event, retrieving the average diagnostic interval would require the `DomInfoUpdateTask` to maintain a large cache of last update times for every poll. To reduce the overhead of maintaining such a large cache, we use the Exponentially Weighted Moving Average (EWMA) to calculate the `diagnostics_update_interval`. This approach provides a smooth and responsive average of the update intervals, allowing us to store a single `diagnostics_update_interval` and retrieve the average diagnostic update interval efficiently. An alpha value of 0.1 is used for the EWMA calculation to provide a smooth average while still being responsive to changes in the update intervals.
**Formula:**
diff --git a/doc/platform_api/CMIS_and_C-CMIS_support_for_ZR.md b/doc/platform_api/CMIS_and_C-CMIS_support_for_ZR.md
index ebaae94c2b2..3be06d85e22 100644
--- a/doc/platform_api/CMIS_and_C-CMIS_support_for_ZR.md
+++ b/doc/platform_api/CMIS_and_C-CMIS_support_for_ZR.md
@@ -1,9 +1,9 @@
## CMIS and C-CMIS support for ZR on SONiC
### 1. Overview
-Common Management Interface Specification (CMIS) is defined for pluggables or on-board modules to communicate with the registers [CMIS v5.0](http://www.qsfp-dd.com/wp-content/uploads/2021/05/CMIS5p0.pdf). With a clear difinition of these registers, modules can set the configurations or get the status, to achieve the basic level of monitor and control.
+Common Management Interface Specification (CMIS) is defined for pluggables or on-board modules to communicate with the registers [CMIS v5.0](http://www.qsfp-dd.com/wp-content/uploads/2021/05/CMIS5p0.pdf). With a clear definition of these registers, modules can set the configurations or get the status, to achieve the basic level of monitor and control.
-CMIS is widely used on modules based on a Two-Wire-Interface (TWI), including QSFP-DD, OSFP, COBO and QSFP modules. However, new requirements emerge with the introduction of coherent optical modules, such as 400G ZR. 400G ZR is the first type of modules to require definitions on coherent optical specifications, a field CMIS does not touch on. The development of C(coherent)-CMIS aims to solve this issue [C-CMIS v1.1](https://www.oiforum.com/wp-content/uploads/OIF-C-CMIS-01.1.pdf). It is based on CMIS but incroporates more definitions on registers in the extended space, regarding the emerging demands on coherent optics specifications.
+CMIS is widely used on modules based on a Two-Wire-Interface (TWI), including QSFP-DD, OSFP, COBO and QSFP modules. However, new requirements emerge with the introduction of coherent optical modules, such as 400G ZR. 400G ZR is the first type of modules to require definitions on coherent optical specifications, a field CMIS does not touch on. The development of C(coherent)-CMIS aims to solve this issue [C-CMIS v1.1](https://www.oiforum.com/wp-content/uploads/OIF-C-CMIS-01.1.pdf). It is based on CMIS but incorporates more definitions on registers in the extended space, regarding the emerging demands on coherent optics specifications.
The scope of this work is to develop APIs for both CMIS and C-CMIS to support 400G ZR modules on SONiC.
@@ -23,7 +23,7 @@ The following diagram shows how the CLI interfaces with the module registers thr
|| /\
\/ ||
------------------------- ---------------------------------
-|lpmode|freq|TXPow|looback| |xcvr_info|xcvr_dom|xcvr_status|PM|
+|lpmode|freq|TXPow|loopback| |xcvr_info|xcvr_dom|xcvr_status|PM|
------------------------- ---------------------------------
|| /\
\/ ||
@@ -1140,7 +1140,7 @@ def get_VDM_page(port, page):
if page not in [0x20, 0x21, 0x22, 0x23]:
raise ValueError('Page not in VDM Descriptor range!')
VDM_descriptor = struct.unpack(f'{PAGE_SIZE}B', read_reg(port, page, PAGE_OFFSET, PAGE_SIZE))
- # Odd Adress VDM observable type ID, real-time monitored value in Page + 4
+ # Odd Address VDM observable type ID, real-time monitored value in Page + 4
VDM_typeID = VDM_descriptor[1::2]
# Even Address
# Bit 7-4: Threshold set ID in Page + 8, in group of 8 bytes, 16 sets/page
@@ -1544,7 +1544,7 @@ The second step is to start CDB download by writing the header of start header s
The third step is to repeatedly read from the given firmware file and write to the payload space advertised from the first step. We use CDB command 0103h to write to the local payload; we use CDB command 0104h to write to the extended paylaod. This step repeats until it reaches end of the firmware file, or the CDB status failed.
The last step is to complete the firmware upgrade with CDB command 0107h.
Note that if the download process fails anywhere in the middle, we need to run CDB command 0102h to abort the upgrade before we restart another upgrade process.
-After the firmware download finishes. The firmware will be run and committed with CDB command 0109h and 010Ah. We also check the currently running and committed firmware iamge version by CDB command 0100h before and after the entire firmware upgrade process to confirm the module switched to the updated firmware.
+After the firmware download finishes. The firmware will be run and committed with CDB command 0109h and 010Ah. We also check the currently running and committed firmware image version by CDB command 0100h before and after the entire firmware upgrade process to confirm the module switched to the updated firmware.
A CDB command is triggered when byte 0x9F: 129 is written. This requires we break a CDB command into two written pieces:
1. write bytes from 0x9F: 130 till the message ends.
2. write bytes 0x9F: 128-129.
@@ -1572,7 +1572,7 @@ def get_module_FW_info(port):
print('Get module FW info')
rlplen, rlp_chkcode, rlp = cdb.cmd0100h(port)
if cdb.cdb_chkcode(rlp) == rlp_chkcode:
- # Regiter 9Fh:136
+ # Register 9Fh:136
fwStatus = rlp[0]
# Registers 9Fh:138,139; 140,141
print('Image A Version: %d.%d; BuildNum: %d' %(rlp[2], rlp[3], ((rlp[4]<< 8) | rlp[5])))
diff --git a/doc/platform_api/new_platform_api.md b/doc/platform_api/new_platform_api.md
index 08e3c8a59b7..6240b748251 100644
--- a/doc/platform_api/new_platform_api.md
+++ b/doc/platform_api/new_platform_api.md
@@ -65,7 +65,7 @@ Challenge: Attempt to create a standardized, unified API to interface with all c
2. Copy the sonic_platform Python wheel to the appropriate /usr/share/sonic/device// directory, which gets mounted in the Docker containers
- When the Platform Monitor (PMon) container starts, it will check whether a "sonic_platform" package is installed. If not, it will attempt to install a "sonic_platform\*.whl" file in the mounted directory as mentioned above.
- In the host system, applications will interact with the platform API for things like watchdog and reboot cause
-- Daemons running in pmon container will be responsible for updating Redis State database with current metrics/status from platfrom hardware
+- Daemons running in pmon container will be responsible for updating Redis State database with current metrics/status from platform hardware
- Command-line utilities in host image will query State DB to retrieve current platform peripheral metrics
- For more real-time data, such as transceiver optical data, a mechanism can be implemented CLI can notify daemons to retrieve data by writing to DB
diff --git a/doc/platform_json_enhancement.md b/doc/platform_json_enhancement.md
index efa312d79d3..dcb9cb78ef6 100755
--- a/doc/platform_json_enhancement.md
+++ b/doc/platform_json_enhancement.md
@@ -26,7 +26,7 @@ This document provides information on the enhancements for platform capability f
Each networking switch has a set of platform components (e.g: Fans, PSUs, LEDs, etc.) and these components in each platform can have different characteristics (like supported colors for a LED). In a given platform, the components could be controlled by a dedicated platform controller (like BMC) or the NOS running on the CPU is required to control it and in the former the control of the components from the NOS could be limited.
-In SONiC the platform components' supported attributes are made available via Platform API, but certain platform specific capabilties for the components are not available for the applications.
+In SONiC the platform components' supported attributes are made available via Platform API, but certain platform specific capabilities for the components are not available for the applications.
This document provides the enhancement for `platform.json` to address the above issue.
@@ -36,7 +36,7 @@ Currently, `platform.json` is used for providing the expected structure of the p
### Platform capabilities field
-A new set of `capabilities` fields are introduced in platform.json, for providing platform specific capablities on control and characteristics of the components.
+A new set of `capabilities` fields are introduced in platform.json, for providing platform specific capabilities on control and characteristics of the components.
For each component's attribute, the defined `capabilities` fields are as follows:
diff --git a/doc/pmon/pmon-chassis-design.md b/doc/pmon/pmon-chassis-design.md
index e2f751c8cc4..aafcf6fe4c5 100644
--- a/doc/pmon/pmon-chassis-design.md
+++ b/doc/pmon/pmon-chassis-design.md
@@ -76,22 +76,22 @@ At a functional level of a chassis, SONiC will manage supervisor-cards, line car
* The Supervisor monitors PSUs of the chassis.
* LEDs and Transceivers are present on line-cards and can be managed via line-card's SONiC platform instances.
* Some of these perpherals are plug-able and hot-swap capable.
-* In general, VOQ chassis has midplane ethernet which interconnects line-cards and supervisor together for its internal communication. This should be initalized upon platform booting and can be used as IP connectivity between supervisor, line-cards.
+* In general, VOQ chassis has midplane ethernet which interconnects line-cards and supervisor together for its internal communication. This should be initialized upon platform booting and can be used as IP connectivity between supervisor, line-cards.
* Each line-card will have management interface either directly to external management interface or via internal midplane ethernet.
### 2.2. Chassis Platform Stack
-In a modular disaggregated SONiC software architecture, each line-card will run an instance of SONiC platform stack and the Supervisor would run its own instance of SONiC platform stack. Each line-card resources are manged as independent fixed platform and also providing all the above functional requirements to operate the chassis. Below picture describes high level view of the platform stack.
+In a modular disaggregated SONiC software architecture, each line-card will run an instance of SONiC platform stack and the Supervisor would run its own instance of SONiC platform stack. Each line-card resources are managed as independent fixed platform and also providing all the above functional requirements to operate the chassis. Below picture describes high level view of the platform stack.
* Each line-card & supervisor-card will have its own ONIE_PLATFORM string to differentiate between each other and also variation of it.
-* The Supervisor wont run any protocol stack except SWSS, SyncD dockers for managing Switch Fabric.
+* The Supervisor won't run any protocol stack except SWSS, SyncD dockers for managing Switch Fabric.
* Each line-card & supervisor-card would run one instance of PMON container.
* Each line-card & supervisor-card would run one instance of redis server for common platform monitoring (host network) and also uses per-asic redis for SFP monitoring.
-* The supervisor-card & line-card could communicate over midplane ethernet. In order to provide this IP connectivty between supervisor & line card, midplane ethernet drivers are run on host network namespace.
+* The supervisor-card & line-card could communicate over midplane ethernet. In order to provide this IP connectivity between supervisor & line card, midplane ethernet drivers are run on host network namespace.
* Each line-card & supervisor-card gets IP address (internal network) assigned to this midplane ethernet based on slot information.
* The supervisor-card PMON will have all sensors readings via either fetching line-card redis servers(subscribe to multiple servers) or global redis db on the Supervisor(publish to single server).
-* SONiC on a fixed platform has put together PMON 2.0 API's for platform vendors to implement peripheral drivers (kernel or userspace). Most of the existing PMON 2.0 API's will be used for chassis and some key changes and enhancments required as detailed below.
+* SONiC on a fixed platform has put together PMON 2.0 API's for platform vendors to implement peripheral drivers (kernel or userspace). Most of the existing PMON 2.0 API's will be used for chassis and some key changes and enhancements required as detailed below.
* The supervisor-card will provide driver implementation to obtain line-card status such as present, empty.
## 3. Detailed Workflow
@@ -101,7 +101,7 @@ SONiC supports ONIE as a boot method and also provides vendor specific boot meth
#### 3.1.1 Supervisor Boot Process
-Supervisor card can be booted using ONiE method. Upon boot, unique ONIE_PLATFORM string will be provided in a ONIE firmware to differentiate the cards and services/dockers it could start via systemd-generator. In case of supervisor card, there wont be dockers like BGP, LLDP, etc started. This service list is included as part of platform specific service list file.
+Supervisor card can be booted using ONiE method. Upon boot, unique ONIE_PLATFORM string will be provided in a ONIE firmware to differentiate the cards and services/dockers it could start via systemd-generator. In case of supervisor card, there won't be dockers like BGP, LLDP, etc started. This service list is included as part of platform specific service list file.
```
device/
@@ -145,7 +145,7 @@ In order to allow direct access to line-cards from outside of the chassis over e
1. Supervisor can create virtual switch (linux bridge) and all add midplane ethernet and external management interface on this bridge. This is the L2 mode of operation but internal communication and external L2 stations traffic will be seen inside this midplane ethernet.
2. IP Routing: Midplane ethernet could be configured with externally reachable network (announced via any routing protocols), this requires mgmt interface on the Supervisor to run routing protocol which isn't common deployment.
-3. Statically assigned externally reachable management IP address per line-card via chassis-d and use NAT to map external/internal midplane IP address. In this case, internal midplane ethernet traffic wont be seen in a external management network and only direct communication allowed using NAT rules.
+3. Statically assigned externally reachable management IP address per line-card via chassis-d and use NAT to map external/internal midplane IP address. In this case, internal midplane ethernet traffic won't be seen in a external management network and only direct communication allowed using NAT rules.
Allowing DHCP relay or DHCP client on these internal midplane ethernet aren't considered for first phase of the design.
@@ -221,7 +221,7 @@ Configuration will be provided to administratively bring down a line-card or fab
Configuration to administratively bring down the module
#config chassis modules shutdown
-Configuration to remove the adminstrative down state of module
+Configuration to remove the administrative down state of module
#config chassis modules startup
```
#### Config-DB Schema
@@ -281,7 +281,7 @@ One of the functional requirement for chassis is to manage and monitor the power
* PSUd will get the power-capacity of each PSU.
* PSUd will calculate the total power capacity from power-capacity of each PSU multiplied by number of PSUs with valid status.
* PSUd will get fixed maximum power requirements of each type of line-card, each SFM and each FAN.
-* PSUd will calculate the total power required as a sum total of power-required of each type of card multipled by maxium power requirement of that card.
+* PSUd will calculate the total power required as a sum total of power-required of each type of card multiplied by maximum power requirement of that card.
* PSUd will set a Master-LED state based on power available vs power required.
We do not see a requirement for real-time monitoring of current power usage of each card.
@@ -419,7 +419,7 @@ Thermal 5 59 68 0 N/A N/A
#### Requirements
* Database connections per namespace - Database dockers run per namespace and PMON processes need to connect to each of these database instances.
-* Update per namespace port status - The pmon processes will need to run per-asic specific functinality ina a separate thread.
+* Update per namespace port status - The pmon processes will need to run per-asic specific functionality ina a separate thread.
Two approaches were discussed as part of the design:
* Approach-1 - Existing process and threads will connect/subscribe to all databases across per-asic namespace. This is the preferred approach and has been documented in https://github.com/sonic-net/SONiC/blob/master/doc/pmon/pmon_multiasic_design.md.
@@ -456,7 +456,7 @@ Below is a code snippet to connect to State-DB. In src/sonic-platform-daemons/so
#### Multi-thread support
-Below is a code snippet to run namespace specific funtionality per thread. In src/sonic-platform-daemons/sonic-xcvrd/scripts/xcvrd:
+Below is a code snippet to run namespace specific functionality per thread. In src/sonic-platform-daemons/sonic-xcvrd/scripts/xcvrd:
```
# Run daemon
def run(self):
@@ -486,11 +486,11 @@ Below is a code snippet to run namespace specific funtionality per thread. In sr
```
-Additonal new APIs like *set_namespace()* and *get_namespace()* can be provided ina chassis_base.py which can be set by PMON processes. This will enable modules supporting platform 2.0 to be aware or query which namespace they are running ina.
+Additional new APIs like *set_namespace()* and *get_namespace()* can be provided ina chassis_base.py which can be set by PMON processes. This will enable modules supporting platform 2.0 to be aware or query which namespace they are running ina.
#### Callflow
-
+
#### Show commands
@@ -594,14 +594,14 @@ FRONT-PANEL INTERFACE STATUS TABLE
#### 3.3.5 Syseepromd
-Syseepromd will run on supervisor and line-cards indepenedently and monitor for any changes in syseeprom. The functionality is similar to fixed platform devices.
+Syseepromd will run on supervisor and line-cards independently and monitor for any changes in syseeprom. The functionality is similar to fixed platform devices.
#### 3.3.6 Midplane Ethernet
To manage and monitor midplace ethernet, the following vendor-specific PMON 2.0 APIs can be introduced:
* API to initialize the midplane on both supervisor and line cards - init_midplane_switch()
- * This API will *not* be used to intialize the drivers or configure the IP-address. The drivers should be initialized and IP-addresses should be configured before the Database-dockers are brought up.
+ * This API will *not* be used to initialize the drivers or configure the IP-address. The drivers should be initialized and IP-addresses should be configured before the Database-dockers are brought up.
* APIs to check midplane connectivity:
* On line-card to check if the Supervisor is reachable via midplane - is_midplane_supervisor_reachable()
* On the Supervisor to check if line-card on slot is reachable via midplane - is_midplane_linecard_reachable(slot)
diff --git a/doc/pmon/pmon-chassis-requirements.md b/doc/pmon/pmon-chassis-requirements.md
index 5d33c05169a..24c917be4ec 100644
--- a/doc/pmon/pmon-chassis-requirements.md
+++ b/doc/pmon/pmon-chassis-requirements.md
@@ -13,7 +13,7 @@
2. On RP the reboot command should reboot the entire system (RP and LC). . Expectation is Peer node should detect link down when reboot is given on RP.
3. Ungraceful Reboot of Supervisor should bring all LC's. LC's should not run headless.
4. Config shut/unshut of LC will be supported as per the Chassis-d design.
-5. Generate syslog for all the critical events and share the threshold (for appropriate/needed components) in documents and recommended for given threshold range. Expectation is we will bind syslog to our Alert Orchestration system and perform recommnded action based on the documents.
+5. Generate syslog for all the critical events and share the threshold (for appropriate/needed components) in documents and recommended for given threshold range. Expectation is we will bind syslog to our Alert Orchestration system and perform recommended action based on the documents.
6. PCI-e issue of not able to detect FC ASIC’s and LC ASIC’s and syslog for same.https://github.com/sonic-net/SONiC/blob/master/doc/pcie-mon/pcie-monitoring-services-hld.md.
7. HW-Watchdog adhering to current SONiC behavior. Start before reboot and explicitly disabled post reboot by SONiC.
8. chassisd daemon support on both LC and RP with all fields of table "CHASSIS_MODULE_TABLE|xxxx” correctly populated.
@@ -33,8 +33,8 @@
## 2. Future Requirements/Enhancements:
1. Generic console for LC using . Possible using this: https://github.com/Azure/SONiC/blob/master/doc/console/SONiC-Console-Switch-High-Level-Design.md
-2. Auto Handling by Platfrom SW to reboot/shutdown the HW Component when detecting the critical Fault’s.
+2. Auto Handling by Platform SW to reboot/shutdown the HW Component when detecting the critical Fault’s.
3. Module/Chassis/Board LED’s . Need general infra enhancement of led daemon and show commands.
4. Temperature Measuring Category Enhancements. More Granular and Increase Polling Interval for same. Also show command optimize not dump all sesors and filter based on location.
-5. Move Voltage and Current sensors support from existing sensorsd/libsensors model to PMON/ thermalCtld model This provide ability/mechanism in SONiC NOS to poll for board’s Voltage and Current sensors (from platform) for power alogorithm.
+5. Move Voltage and Current sensors support from existing sensorsd/libsensors model to PMON/ thermalCtld model This provide ability/mechanism in SONiC NOS to poll for board’s Voltage and Current sensors (from platform) for power algorithm.
6. Support for Midplane Switch Counters (Debugging) /Modifying QOS Properties if needed (Performance) (Applicable for HW based Midplane switch).
diff --git a/doc/pmon/pmon-enhancement-design.md b/doc/pmon/pmon-enhancement-design.md
index bab0e5c2124..afe67b27f52 100644
--- a/doc/pmon/pmon-enhancement-design.md
+++ b/doc/pmon/pmon-enhancement-design.md
@@ -59,9 +59,9 @@ Part of transceiver related data already in the DB which are collected by Xcvrd,
### 1.4 Misc platform related data collection
-For the platform hwsku, AISC name, reboot cause and other datas from syseeprom will be write to DB during the start up. A new separate task will be added to collect all of the data, since these data will not change over time, so this task doing one shot thing, will exit after post all the data to DB.
+For the platform hwsku, AISC name, reboot cause and other data from syseeprom will be write to DB during the start up. A new separate task will be added to collect all of the data, since these data will not change over time, so this task doing one shot thing, will exit after post all the data to DB.
-Detail datas that need to be collected please see the below DB Schema section.
+Detail data that need to be collected please see the below DB Schema section.
### 1.4 DB Schema for Platform related data
@@ -69,15 +69,15 @@ All the peripheral devices data will be stored in state DB.
#### 1.5.1 Platform Table
- ; Defines information for a platfrom
- key = PLATFORM_INFO|platform_name ; infomation for the chassis
+ ; Defines information for a platform
+ key = PLATFORM_INFO|platform_name ; information for the chassis
; field = value
chassis_list = STRING ; chassis name list
#### 1.5.2 Chassis Table
; Defines information for a chassis
- key = CHASSIS_INFO|chassis_name ; infomation for the chassis
+ key = CHASSIS_INFO|chassis_name ; information for the chassis
; field = value
presence = BOOLEAN ; presence of the chassis
model = STRING ; model number from syseeprom
@@ -92,8 +92,8 @@ All the peripheral devices data will be stored in state DB.
product_name = STRING ; product name from syseeprom
mac_addr_num = INT ; mac address numbers from syseeprom
- manufacture_date = STRING ; manufature date from syseeprom
- manufacture = STRING ; manufaturer from syseeprom
+ manufacture_date = STRING ; manufacture date from syseeprom
+ manufacture = STRING ; manufacturer from syseeprom
platform_name = STRING ; platform name from syseeprom
onie_version = STRING ; onie version from syseeprom
crc32_checksum = INT ; CRC-32 checksum from syseeprom
@@ -290,7 +290,7 @@ Design doc for new platform API [design doc](https://github.com/sonic-net/SONiC/
## 4. Pmon daemons dynamically loading
We have multi pmon daemons for different peripheral devices, like xcvrd for transceivers, ledd for front panel LEDs, etc. Later on we may add more for PSU, fan.
-But not all the platfrom can support(or needed) all of these daemons due to various reasons. Thus if we arbitrarily load all the pmon daemons in all the platfrom, some platform may encounter into some errors. To avoid this, pmon need a capability to load the daemons dynamically for a specific platfrom.
+But not all the platform can support(or needed) all of these daemons due to various reasons. Thus if we arbitrarily load all the pmon daemons in all the platform, some platform may encounter into some errors. To avoid this, pmon need a capability to load the daemons dynamically for a specific platform.
The starting of the daemons inside pmon is controlled by supervisord, to have dynamically control on it, an approach is to manipulate supervisord configuration file. For now pmon superviosrd only have a common configuration file which applied to all the platforms by default.
diff --git a/doc/pmon/pmon-sensormon.md b/doc/pmon/pmon-sensormon.md
index 31ec5c8be50..d6433394c05 100644
--- a/doc/pmon/pmon-sensormon.md
+++ b/doc/pmon/pmon-sensormon.md
@@ -40,7 +40,7 @@ Note that temperature sensor devices are managed via SONiC ThermalCtlD daemon to
Linux does provide some support of voltage and current sensor monitoring using lmsensors/hwmon infrastructure. However there are a few limitations with that
- Devices not supported with Hwmon are not covered
-- Simple devices which donot have an inbuilt monitoring functions do not generate any alarms
+- Simple devices which do not have an inbuilt monitoring functions do not generate any alarms
- Platform specific thresholds for monitoring are not available
The solution proposed in this document tries to address these limitations by extending the coverage to a larger set of devices and providing platform specific thresholds for sensor monitoring.
@@ -79,7 +79,7 @@ The following SONiC repositories will have changes
#### sonic-platform-daemons
-SensorMon will be a new daemon that will run in PMON container. It will retrieve a list of sensors of different sensor types from the platform during initialization. Subsequently, it will poll the sensor devices on a periodic basis and update their measurments in StateDb. SensorMon will also raise syslogs on alarm conditions.
+SensorMon will be a new daemon that will run in PMON container. It will retrieve a list of sensors of different sensor types from the platform during initialization. Subsequently, it will poll the sensor devices on a periodic basis and update their measurements in StateDb. SensorMon will also raise syslogs on alarm conditions.
Following is the DB schema for voltage and current sensor data.
@@ -97,7 +97,7 @@ Following is the DB schema for voltage and current sensor data.
warning_status = boolean ; Sensor value in range
timestamp = string ; Last update time
maximum_voltage = float ; Maximum recorded measurement
- minimum_voltage = float ; Mininum recorded measurement
+ minimum_voltage = float ; Minimum recorded measurement
##### Current Sensor StateDb Schema
@@ -113,7 +113,7 @@ Following is the DB schema for voltage and current sensor data.
warning_status = boolean ; Sensor value in range
timestamp = string ; Last update time
maximum_current = float ; Maximum recorded measurement
- minimum_current = float ; Mininum recorded measurement
+ minimum_current = float ; Minimum recorded measurement
#### sonic-platform-common
@@ -125,7 +125,7 @@ Module base class will also be enhanced with similar methods for retrieving sens
New base classes will be introduced for new sensor types.
VsensorBase is introduced for voltage sensor objects.
-IsensorBase is introdued for current sensor objects.
+IsensorBase is introduced for current sensor objects.
The classes will have methods to retrieve threshold information, sensor value and min/max recorded values from the sensor.
@@ -174,7 +174,7 @@ It is advised to monitor the sensor alarms and use that to debug and identify an
FJul 27 08:26:32.561330 sonic WARNING pmon#sensormond: High voltage warning: VP0P75_CORE_NPU2 current voltage 880mV, high threshold 856mV
-The alarm condition will be visible in the CLI ouputs for sensor data and system health.
+The alarm condition will be visible in the CLI outputs for sensor data and system health.
e.g
root@sonic:/home/cisco# show platform voltage
diff --git a/doc/pmon/sonic_platform_test_plan.md b/doc/pmon/sonic_platform_test_plan.md
index cf12a919ec2..ba08b6b4c20 100644
--- a/doc/pmon/sonic_platform_test_plan.md
+++ b/doc/pmon/sonic_platform_test_plan.md
@@ -43,7 +43,7 @@ To verify that the hw-management package works as expected, the test cases need
* Mellanox ACS-MSN2740
* Mellanox ACS-MSN3700
-The test cases are groupd in two categories:
+The test cases are grouped in two categories:
* Common test cases for all vendors.
* Test cases specific for Mellanox platforms.
@@ -55,7 +55,7 @@ In common test cases, some steps are platform dependent. Detailed information wi
A test suite will install an HTTP server in the PMon container of the DuT. This HTTP server will convert URLs into platform API calls, returning the results of the API call in the HTTP response. All platform API methods will be exercised in this manner, ensuring that:
-1. The vendor has implmented the method for the particular platform
+1. The vendor has implemented the method for the particular platform
2. The API call returned 'sane' data (type is correct, etc.)
3. Where applicable, the data returned is appropriate for the platform being tested (number of fans, number of transceivers, etc.)
4. Where applicable, the data returned is appropriate for the specific DuT (serial number, system EERPOM data, etc.)
@@ -453,7 +453,7 @@ This test case needs to frequently check various status, the status to be checke
* `redis-cli -n 6 keys TRANSCEIVER_INFO*`
* CPU and memory usage: `top`
-Expected results of checking varous status:
+Expected results of checking various status:
* Services syncd and swss should be active(running)
* Service hw-management should be active(exited) - **Mellanox specific**
* All interface and port-channel status should comply with current topology.
@@ -494,7 +494,7 @@ This test case needs to frequently check various status, the status to be checke
* `redis-cli -n 6 keys TRANSCEIVER_INFO*`
* CPU and memory usage: `top`
-Expected results of checking varous status:
+Expected results of checking various status:
* Services syncd and swss should be active(running)
* Service hw-management should be active(exited) - **Mellanox specific**
* All interface and port-channel status should comply with current topology.
@@ -535,7 +535,7 @@ This test case needs to frequently check various status, the status to be checke
* `redis-cli -n 6 keys TRANSCEIVER_INFO*`
* CPU and memory usage: `top`
-Expected results of checking varous status:
+Expected results of checking various status:
* Services syncd and swss should be active(running)
* Service hw-management should be active(exited) - **Mellanox specific**
* All interface and port-channel status should comply with current topology.
@@ -576,7 +576,7 @@ This test case needs to frequently check various status, the status to be checke
* `redis-cli -n 6 keys TRANSCEIVER_INFO*`
* CPU and memory usage: `top`
-Expected results of checking varous status:
+Expected results of checking various status:
* Services syncd and swss should be active(running)
* Service hw-management should be active(exited) - **Mellanox specific**
* All interface and port-channel status should comply with current topology and hardware availability:
@@ -728,7 +728,7 @@ New automation required
### Pass/Fail Criteria
* Verify that symbolic links are created under `/var/run/hw-management`. Ensure that there are no invalid symbolic link
* Check current FAN speed against max and min fan speed, also check the the fan speed tolerance, insure it's in the range
-* Check thermal valules(CPU, SFP, PSU,...) against the max and min value to make sure they are in the range.
+* Check thermal values(CPU, SFP, PSU,...) against the max and min value to make sure they are in the range.
### Automation
New automation required
@@ -749,7 +749,7 @@ New automation required
### Steps
* Get all the connected interfaces
-* Check the presence of the SFP on each interface and corss check the SFP status from the sysfs
+* Check the presence of the SFP on each interface and cross check the SFP status from the sysfs
### Pass/Fail Criteria
* All th SFP shall be presence and SFP status shall be OK.
@@ -769,9 +769,9 @@ New automation required
This section outlines the design of scripts automating the SONiC platform test cases. The new pytest-ansible framework will be used. Sample code can be found [here](https://github.com/sonic-net/sonic-mgmt/tree/master/tests).
## Folder Structure and Script Files
-The pytest framwork supports flexible test discovery. The plan is to put all platform related scripts under `tests/platform`. Command like `pytest tests/platform` would be able to discover all `test_*.py` and `*_test.py` under `tests/platform`. No entry script is required.
+The pytest framework supports flexible test discovery. The plan is to put all platform related scripts under `tests/platform`. Command like `pytest tests/platform` would be able to discover all `test_*.py` and `*_test.py` under `tests/platform`. No entry script is required.
-The folder structure and sript files:
+The folder structure and script files:
```
sonic-mgmt
|-- ansible
@@ -800,7 +800,7 @@ Filename of scripts should follow this pattern:
* All scripts for test cases should start with `test_`.
* Put vendor specific test cases in dedicated folder. For example, all Mellanox specific scripts are put under subfolder "mellanox".
* Scripts hold helper functions or classes should start with `check_`, or other prefix as long as it does not conflict with above two patterns.
-* The `sonic-mgmt/tests/platform/psu_controller.py` script has the definition of psu_controller fixture that is used in `test_platform_info.py`. The psu_controller fixture returns a PSU controller object for controlling the power on/off to PSUs of DUT. This script also defines the interface of PSU controller object in PsuControllerBase class. Vendor specific PSU controller must be implemented as a sublcass of PsuControllerBase and put under vendor subfolder. For example, Mellanox specific PSU controller is impelemented in `sonic-mgmt/tests/platform/mellanox/mellanox_psu_controller.py`.
+* The `sonic-mgmt/tests/platform/psu_controller.py` script has the definition of psu_controller fixture that is used in `test_platform_info.py`. The psu_controller fixture returns a PSU controller object for controlling the power on/off to PSUs of DUT. This script also defines the interface of PSU controller object in PsuControllerBase class. Vendor specific PSU controller must be implemented as a subclass of PsuControllerBase and put under vendor subfolder. For example, Mellanox specific PSU controller is implemented in `sonic-mgmt/tests/platform/mellanox/mellanox_psu_controller.py`.
With this convention, to run just the common test cases, use below commands:
* `py.test tests/platform/test_* `
@@ -830,7 +830,7 @@ The psu_controller fixture will also be implemented in phase 1:
* `tests/platform/psu_controller.py`
* `tests/platform/mellanox/mellanox_psu_controller.py`
-The scripts for testing sensors `ansible/roles/test/tasks/sensors_check.yml` simply calls `ansible/roles/sonic-common/tasks/sensors_check.yml`. We can conver it to pytest in the future.
+The scripts for testing sensors `ansible/roles/test/tasks/sensors_check.yml` simply calls `ansible/roles/sonic-common/tasks/sensors_check.yml`. We can convert it to pytest in the future.
## Scripts to be implemented in phase 2
diff --git a/doc/port-1.6t-support/port-1.6t-support.md b/doc/port-1.6t-support/port-1.6t-support.md
index 1b46d15bcf5..2c95a221930 100644
--- a/doc/port-1.6t-support/port-1.6t-support.md
+++ b/doc/port-1.6t-support/port-1.6t-support.md
@@ -7,7 +7,7 @@
- [2. Scope](#2-scope)
- [3. Definitions/Abbreviations](#3-definitionsabbreviations)
- [4. Overview](#4-overview)
- - [5. High-Level Enchancements](#5-high-level-enchancements)
+ - [5. High-Level Enhancements](#5-high-level-enhancements)
- [5.1. SFF-8024 Additions](#51-sff-8024-additions)
- [5.1.1. Host Electrical Interface](#511-host-electrical-interface)
- [5.1.2. MMF Media Interface](#512-mmf-media-interface)
diff --git a/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md b/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md
index 90f729ec492..206b7f4c4a6 100644
--- a/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md
+++ b/doc/port-add-del-dynamically/dynamic_port_add_del_hld.md
@@ -26,7 +26,7 @@ Before removing a port the user is responsible to remove all dependencies of thi
# About this Manual
This document provides general information about ports creation or removal in SONiC. The creation of ports on the init stage and creating or removing ports after init stage.
# Scope
-This document describes the high level design of orchagent and the impact of creating/removing ports dynamically on other services. The design describes the current implementaion and suggestion to changes that needs to be implemented in order to fully support the dynamic create/remove of ports.
+This document describes the high level design of orchagent and the impact of creating/removing ports dynamically on other services. The design describes the current implementation and suggestion to changes that needs to be implemented in order to fully support the dynamic create/remove of ports.
## Relevant PRs
[PR #7999 Allow cfggen to work on system without ports](https://github.com/sonic-net/sonic-buildimage/pull/7999)
@@ -273,7 +273,7 @@ If we will not use this mechanism we will get a lot of SAI error and with this r
The Problem:
- when a port is added - the lldpcli execution can failed since the host interface is not yet up. oper_state on on APP DB is up but host interface is not up yet.
-- when lldp is removed immediatly after add the lldpcli command wasn't executed yet, the command is still on pending_cmds, there is treatment to remove a port, on lldpmgrd, the command for this port will stay forever on the pending_cmds end each 10 seconds (timeout value) the command will be executed and failed since the host interface is no longer exist.
+- when lldp is removed immediately after add the lldpcli command wasn't executed yet, the command is still on pending_cmds, there is treatment to remove a port, on lldpmgrd, the command for this port will stay forever on the pending_cmds end each 10 seconds (timeout value) the command will be executed and failed since the host interface is no longer exist.
Suggested change:
- Before executing lldpcli command we will check if host interface is up by checking the port status on state db
diff --git a/doc/port-profile-init/port-profile-init-design.md b/doc/port-profile-init/port-profile-init-design.md
index 98eb8ed800f..b251f451a85 100644
--- a/doc/port-profile-init/port-profile-init-design.md
+++ b/doc/port-profile-init/port-profile-init-design.md
@@ -120,7 +120,7 @@ Few checks will be performed in initialization flow.
2. Are ports configured in SAI?
In order to check this, we will query the ports list created in SAI using sai_switch_api->get_switch_attribute() API, while attr id is SAI_SWITCH_ATTR_PORT_LIST.
- If there are ports in the list taken from SAI, they will be proceessed as before and saved in a list for the later comparison logic.
+ If there are ports in the list taken from SAI, they will be processed as before and saved in a list for the later comparison logic.
#### doPortTask Flow
@@ -138,15 +138,15 @@ The same flow will be performed for ports attribute setting.
If bulk set_attribute is supported, set_ports_attribute() API will be called.
Otherwise, setting SAI attributes will be done one by one as before.
-\* Creating Host Interfaces will be done one by one as beofre.
+\* Creating Host Interfaces will be done one by one as before.
An important Note:
-In order to use SAI bulk APIs, the global flag in syncd (-l / --enableBulk) should enable the bulk opertaion.
+In order to use SAI bulk APIs, the global flag in syncd (-l / --enableBulk) should enable the bulk operation.
If this flag will not be provided upon syncd startup, bulk operation will be translated to regular operation. Hence, time will not be enhanced.
Each vendor should enable the flag for it's config_syncd_vendor function in syncd_init_common.sh script.
-Note that this flag will enable bulk opertaions for all available options (e.g. route, vlan and now ports).
+Note that this flag will enable bulk operations for all available options (e.g. route, vlan and now ports).
#### Error Flow
@@ -210,7 +210,7 @@ N/A
After feature is implemented in both SONiC and SAI side, few tests will need to be performed.
* Execute regression test for fast boot and perform time analyze, in order to make sure fast-boot time decreased as expected. In addition, manual time testing for fast-reboot up time.
* A new sonic-mgmt test will need to be added. the test will check fast-reboot with dynamic port breakout.
-* A full regression testing to make sure evertything is working as before.
+* A full regression testing to make sure everything is working as before.
#### Unit Test cases
diff --git a/doc/port-si/Port_SI_Per_Speed.md b/doc/port-si/Port_SI_Per_Speed.md
index 1787722ff0b..da11635529a 100755
--- a/doc/port-si/Port_SI_Per_Speed.md
+++ b/doc/port-si/Port_SI_Per_Speed.md
@@ -131,7 +131,7 @@ The flow of using this json will be referred to as the **_Notify-Media-setting-P
## Port SI configuration (flows)
Currently, the Notify-Media-Settings-Process is carried out only in the initialization phase of xcvrd and whenever a module is plugged in. After applying the port SI per speed enhancements, it will also be carried out upon port speed change events: Whenever a port speed change is detected by listening to CONFIG_DB, Notify-Media-Settings-Process will be called to send the most applicable SI values in the JSON to SAI.
-Port speed changes require invoking the Notify-Media-Settings-Process becuase after such a change, the lane_speed_key used for lookup in the JSON changes accordingly, and the previously configured SI values in the ASIC are no longer relevant.
+Port speed changes require invoking the Notify-Media-Settings-Process because after such a change, the lane_speed_key used for lookup in the JSON changes accordingly, and the previously configured SI values in the ASIC are no longer relevant.
@@ -141,7 +141,7 @@ Port speed changes require invoking the Notify-Media-Settings-Process becuase af
1. Changes in SfpStateUpdateTask thread:
With the port SI per speed enhancements applied, we rely on the lane speed when we lookup in _media_settings,json_. Hence, this flow has to be triggered not only by insertion/removal of modules, but by speed configuration changes as well.
- In order to establish the dependency of port SI configurations on lane speed, we need to be able to monitor speed configuration changes. Therefore, we will add to the SfpStateUpdateTask a listener to detect such changes: a new member will be added to SfpStateUpdateTask to listen to changes in CONFIG_DB.PORT_TABLE, and once such change is detected, _notify_media_settings()_ will be trigerred. Additionally, the SfpStateUpdateTask thread will have a new dictionary that will store the speed and number of lanes for each port.
+ In order to establish the dependency of port SI configurations on lane speed, we need to be able to monitor speed configuration changes. Therefore, we will add to the SfpStateUpdateTask a listener to detect such changes: a new member will be added to SfpStateUpdateTask to listen to changes in CONFIG_DB.PORT_TABLE, and once such change is detected, _notify_media_settings()_ will be triggered. Additionally, the SfpStateUpdateTask thread will have a new dictionary that will store the speed and number of lanes for each port.
@@ -223,7 +223,7 @@ Port speed changes require invoking the Notify-Media-Settings-Process becuase af
# Unit Test
- Generation of keys in the new format: Expand the _test_get_media_settings_key()_ method to create a dictionary that contains a mapping between a port and its port speed and lane count. Then call _get_media_settings_key()_ with that dictionary and assert that a valid lane_speed_key was composed.
-- The lookup functionality works seamlessly with both the new and legacy JSON formats: Create a new test, _test_get_media_settings_value()_, that gets the (vendor_key, media_key, lane_speed_key) tuple. This test will perform the lookup using this tuple in two instances of the media_settings.json file: one from the updated format and one from the current format. The only difference between these two JSONs is that the first contains the hierarchy level that corresponds to the lane_speed_key received, while the latter doesn't. Everyhing else is similar for the two JSONs. Both lookup should end up with a match, extracting the same values from the JSONs.
+- The lookup functionality works seamlessly with both the new and legacy JSON formats: Create a new test, _test_get_media_settings_value()_, that gets the (vendor_key, media_key, lane_speed_key) tuple. This test will perform the lookup using this tuple in two instances of the media_settings.json file: one from the updated format and one from the current format. The only difference between these two JSONs is that the first contains the hierarchy level that corresponds to the lane_speed_key received, while the latter doesn't. Everything else is similar for the two JSONs. Both lookup should end up with a match, extracting the same values from the JSONs.
This test verifies backward compatibility and ensures that the updated JSON format does not cause any issues for other vendors.
- PortsOrchagent tests:
diff --git a/doc/port_auto_neg/auto-fec.md b/doc/port_auto_neg/auto-fec.md
index 5112394c311..e685853f457 100644
--- a/doc/port_auto_neg/auto-fec.md
+++ b/doc/port_auto_neg/auto-fec.md
@@ -206,6 +206,6 @@ Below table gives details on when db_migrator will be needed when vendor impleme
#### VS Test cases
1. Add SWSS VS test to query SAI_PORT_ATTR_AUTO_NEG_FEC_MODE_OVERRIDE and if supported expect SAI_PORT_ATTR_AUTO_NEG_FEC_MODE_OVERRIDE to be set to true when FEC is configured.
-2. If SAI_PORT_ATTR_AUTO_NEG_FEC_MODE_OVERRIDE is not suppored it should not be set when configuring FEC
+2. If SAI_PORT_ATTR_AUTO_NEG_FEC_MODE_OVERRIDE is not supported it should not be set when configuring FEC
3. Set FEC mode to auto and AN=true verify SAI_PORT_ATTR_AUTO_NEG_FEC_MODE_OVERRIDE is set to false
4. Set FEC mode to auto and AN=false verify no FEC mode is programmed
diff --git a/doc/port_auto_neg/port-auto-negotiation-design.md b/doc/port_auto_neg/port-auto-negotiation-design.md
index d762e38fa10..8961518e59e 100644
--- a/doc/port_auto_neg/port-auto-negotiation-design.md
+++ b/doc/port_auto_neg/port-auto-negotiation-design.md
@@ -684,7 +684,7 @@ While it is possible to use CLI/CONFIG_DB for setting the port auto negotiation
Unfortunately, it's not straightforward for users to identify which interface type is most appropriate to the attached transceivers, and the link will not get up unless the connected devices are both advertising the same interface type. This requires domain knowledge, correct EERPOM information and the individual hardware datasheet review process. Hence it's recommended to use [media_settings.json](https://github.com/sonic-net/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) to automate the while process. A interface type update request from [media_settings.json](https://github.com/sonic-net/SONiC/blob/master/doc/media-settings/Media-based-Port-settings.md) is triggered by the transceiver detection of pmon#xcvrd, which leverages **APPL_DB** instead of **CONFIG_DB**, hence the requests will not be blocked by **portsyncd**. If the interface type update request arrives when autoneg is enabled, it should alter the advertisement and restart the autoneg. That said, if the user has interface type configured in both CONFIG_DB and media_settings.json, it wouldn't be possible to predict which would take precedence as there is no logic giving one priority over other. Hence please be sure to use either CLI/CONFIG_DB or media_settings.json at a time, never have both of them activated.
- **Pre-Emphasis**
- Typically, prior to some process, such as transmission over cable, or recording to phonograph record or tape, the input frequency range most susceptible to noise is boosted. This is referred to as "pre-emphasis" - before the process the signal will undergo. While this is rarely necessay to the native RJ45 ports, it's important to SFP/QSFP/QSFPDD ports. For optical arrangements (e.g. SR/LR/DR transceivers), the loss is miniscule. The loss budget allocated for the host PCB board is small, which implies the pre-emphasis calibrated is supposed to work regardless of the fiber cable attached. On the other hand, on passive media, there is a significant amount of frequency dependent loss and the channel loss can range up to the CR/KR loss spec. It is therefore important and useful to activate Link-Training to "train" the TX FIR in both directions to help equalize that loss. IEEE 802.3 Clause 72, Clause 73 and Clause 93 define the auto-negotiation and link-training support for CR/KR transceivers, while the support of opticals (e.g. SR/LR/DR) are never in the scope. On the other hand, when autoneg is enabled, the link-training will also be activated, and the link-training handshake will only get started after negotiation if autoneg is enabled. Furtherly, link-training is to dynamically tune hardware signals at runtime, as a result, the static pre-emphasis parameters in media_setting.json is not necessary and will not be taken into autoneg process.
+ Typically, prior to some process, such as transmission over cable, or recording to phonograph record or tape, the input frequency range most susceptible to noise is boosted. This is referred to as "pre-emphasis" - before the process the signal will undergo. While this is rarely necessary to the native RJ45 ports, it's important to SFP/QSFP/QSFPDD ports. For optical arrangements (e.g. SR/LR/DR transceivers), the loss is minuscule. The loss budget allocated for the host PCB board is small, which implies the pre-emphasis calibrated is supposed to work regardless of the fiber cable attached. On the other hand, on passive media, there is a significant amount of frequency dependent loss and the channel loss can range up to the CR/KR loss spec. It is therefore important and useful to activate Link-Training to "train" the TX FIR in both directions to help equalize that loss. IEEE 802.3 Clause 72, Clause 73 and Clause 93 define the auto-negotiation and link-training support for CR/KR transceivers, while the support of opticals (e.g. SR/LR/DR) are never in the scope. On the other hand, when autoneg is enabled, the link-training will also be activated, and the link-training handshake will only get started after negotiation if autoneg is enabled. Furtherly, link-training is to dynamically tune hardware signals at runtime, as a result, the static pre-emphasis parameters in media_setting.json is not necessary and will not be taken into autoneg process.
### Warmboot and Fastboot Design Impact
diff --git a/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md b/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md
index 32c177564ea..c17fb301913 100644
--- a/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md
+++ b/doc/port_buffer_drop_counters/sonic_port_buffer_drop_counters.md
@@ -8,7 +8,7 @@
* [Revision](#revision)
* [About this Manual](#about-this-manual)
* [Scope](#scope)
-* [Defintions/Abbreviation](#definitionsabbreviation)
+* [Definitions/Abbreviation](#definitionsabbreviation)
* [1 Overview](#1-overview)
* [2 Requirements](#2-requirements)
- [2.1 Functional Requirements](#21-functional-requirements)
@@ -84,7 +84,7 @@ BUFFER_POOL_WATERMARK_STAT default (10000) enable
```
-#### New imlementation
+#### New implementation
```
admin@sonic:~$ counterpoll show
diff --git a/doc/port_fec-ber/port_fec_ber.md b/doc/port_fec-ber/port_fec_ber.md
index 25a907590e9..644bfe8a8fc 100644
--- a/doc/port_fec-ber/port_fec_ber.md
+++ b/doc/port_fec-ber/port_fec_ber.md
@@ -107,7 +107,7 @@ The following redis DB entries will be access for the BER calculations
|COUNTER_DB |RATES |SAI_PORT_STAT_IF_IN_FEC_CORRECTED_BITS_last | New, RW|number |Last corrected bits counts |
|COUNTER_DB |RATES |SAI_PORT_STAT_IF_IN_FEC_NOT_CORRECTABLE_FRAMES_last |New, RW|number |Last uncorrctedble frame counts |
|COUNTER_DB |RATES |FEC_PRE_BER |New, RW| floating |calculated pre fec BER |
-|COUNTER_DB |RATES |FEC_POST_BER |New, RW| floating | calulated post fec BER |
+|COUNTER_DB |RATES |FEC_POST_BER |New, RW| floating | calculated post fec BER |
|APPL_DB |PORT_TABLE |lanes |R |strings |number of serdes lanes in the port |
|APPL_DB |PORT_TABLE |speed |R |number |port speed |
@@ -156,7 +156,7 @@ Step 4 : assume statistical average error rate as 1e-8 per frame
rs_average_frame_ber = 1e-8
-Step 5: calcuate BER
+Step 5: calculate BER
interval = PORT_STATE poll interval which is 1000 ms currently
@@ -164,7 +164,7 @@ Step 5: calcuate BER
Post FEC BER = (SAI_PORT_STAT_IF_IN_FEC_NOT_CORRECTABLE_FRAMES - SAI_PORT_STAT_IF_IN_FEC_NOT_CORRECTABLE_FRAMES_last) * rs_average_frame_ber / (serdes * lanes_count * interval / 1000)
-Step 6: the following data will be updated and its latest value stored in the COUNTER_DB, RATES table after each iteraction
+Step 6: the following data will be updated and its latest value stored in the COUNTER_DB, RATES table after each interaction
Pre FEC BER , Post FEC BEC, SAI_PORT_STAT_IF_IN_FEC_CORRECTED_BITS_last and SAI_PORT_STAT_IF_IN_FEC_NOT_CORRECTABLE_FRAMES_last
diff --git a/doc/port_fec_flr/port_fec_flr.md b/doc/port_fec_flr/port_fec_flr.md
index 56f69404909..2c7b6676b62 100755
--- a/doc/port_fec_flr/port_fec_flr.md
+++ b/doc/port_fec_flr/port_fec_flr.md
@@ -91,7 +91,7 @@ There are no changes to the current SONiC Architecture.
- Enhance the `portstat` command with the `-f` option (used by the CLI command `show interfaces counters fec-stats`) to include the FLR(O) and FLR(P) columns.
+ counterpoll/main.py:
- - Add a new argument `flr-interval-factor` to the exisiting `counterpoll port` command.
+ - Add a new argument `flr-interval-factor` to the existing `counterpoll port` command.
```
root@sonic:~$ counterpoll port --help
@@ -233,7 +233,7 @@ The image below shows the linear pattern of the codeword error ratio (CER) after
```
-Step 3: Perform linear regresion to arrive at slope and intercept
+Step 3: Perform linear regression to arrive at slope and intercept
slope = (n * Σ(x*y) - Σx * Σy) / (n * Σ(x²) - (Σx)²)
intercept = (Σy - slope * Σx) / n
diff --git a/doc/profiling/sonic_bootchart.md b/doc/profiling/sonic_bootchart.md
index aee21d21e05..e9f0717b860 100755
--- a/doc/profiling/sonic_bootchart.md
+++ b/doc/profiling/sonic_bootchart.md
@@ -29,7 +29,7 @@
SONiC OS is highly modular and composible system, where every new feature is
often implemented as a new script, utility, daemon or docker container. A lot of
-these components start at SONiC boot togather with respect to their dependencies
+these components start at SONiC boot together with respect to their dependencies
requirements. Majority of start scripts use short-living small utilities written
in python, bash or other scripting languages, invoke Jinja2 template generation.
This leads to potential boot time performance degradation that we need a tool to
@@ -191,7 +191,7 @@ Usage example:
- Enable bootchart: "sudo sonic-bootchart enable"
- Perform any kind of reboot: "sudo reboot" or "sudo warm-reboot" or "sudo
fast-reboot"
- - Wait till system reboots and the plot is generated by quering
+ - Wait till system reboots and the plot is generated by querying
"sudo sonic-bootchart show"
#### Manifest (if the feature is an Application Extension)
diff --git a/doc/psud/PSU_daemon_design.md b/doc/psud/PSU_daemon_design.md
index d2c51679375..070ff4eca62 100644
--- a/doc/psud/PSU_daemon_design.md
+++ b/doc/psud/PSU_daemon_design.md
@@ -70,7 +70,7 @@ We will detail the new flows in the following sections.
Basically, there are two scenarios in which a new PSU can be detected:
- On PSU daemon starting, all PSUs installed on the switch are detected
-- On new PSU pulgged, the new PSU is detected
+- On new PSU plugged, the new PSU is detected
When one or more new PSUs is detected and power is good, PSU daemon tries retrieving the warning-suppress and critical threshold for each PSU installed on the switch.
@@ -80,7 +80,7 @@ The PSU power checking will not be checked for a PSU if `NotImplemented` excepti
We use asymmetric thresholds between raising and clearing the alarm for the purpose of creating a hysteresis and avoiding alarm flapping.
-- an alarm will be raised when a PSU's power is rising accross the critical threshold
+- an alarm will be raised when a PSU's power is rising across the critical threshold
- an alarm will be cleared when a PSU's power is dropping across the warning-suppress threshold
In case a unified power threshold is used, the alarm status can flap when the power fluctuates around the threshold. For example, in the following picture, the alarm is cleared every time the PSU power drops across the critical threshold and raised every time the PSU power rises across the critical threshold. By having two thresholds, the alarm won't be cleared and raised so frequently.
diff --git a/doc/ptp/ptp.md b/doc/ptp/ptp.md
index 8f19462a80f..2401e806953 100644
--- a/doc/ptp/ptp.md
+++ b/doc/ptp/ptp.md
@@ -19,7 +19,7 @@ path delay = ((t4-t1) - (t3-t2))/2
offset from master clock = (t2 - t1) - path delay
-
+
Achieving high precision requires hardware timestamping
diff --git a/doc/qos/ECN_and_WRED_statistics_HLD.md b/doc/qos/ECN_and_WRED_statistics_HLD.md
index 6a779b0c5df..70faa7d8169 100644
--- a/doc/qos/ECN_and_WRED_statistics_HLD.md
+++ b/doc/qos/ECN_and_WRED_statistics_HLD.md
@@ -1,454 +1,454 @@
-# WRED and ECN Statistics
-
-
-## Table of Contents
-- [WRED and ECN Statistics](#wred-and-ecn-statistics)
- - [Table of Contents](#table-of-contents)
- - [Revision](#revision)
- - [Scope](#scope)
- - [Abbreviations](#abbreviations)
- - [Overview](#overview)
- - [Requirements](#requirements)
- - [Architecture Design](#architecture-design)
- - [High-Level Design](#high-level-design)
- - [Changes in CONFIG_DB](#changes-in-config_db)
- - [Changes in STATE_DB](#changes-in-state_db)
- - [Changes in FLEX_COUNTER_DB](#changes-in-flex_counter_db)
- - [Changes in COUNTERS_DB](#changes-in-counters_db)
- - [Changes in Orchagent](#changes-in-orchagent)
- - [CLI Changes](#cli-changes)
- - [CLI output on a WRED and ECN queue statistics supported platform](#cli-output-on-a-wred-and-ECN-queue-statistics-supported-platform)
- - [CLI output on a platform which supports WRED drop statistics and does not support ECN statistics](#cli-output-on-a-platform-which-supports-wred-drop-statistics-and-does-not-support-ecn-statistics)
- - [CLI output on a platform which supports ECN statistics and does not support WRED statistics](#cli-output-on-a-platform-which-supports-ecn-statistics-and-does-not-support-wred-statistics)
- - [show interface counters CLI output on a WRED drop statistics supported platform](#show-interface-counters-cli-output-on-a-wred-drop-statistics-supported-platform)
- - [show interface counters on a platform which does not support WRED drop statistics](#show-interface-counters-cli-output-on-a-platform-which-does-not-support-wred-drop-statistics)
- - [SAI API](#sai-api)
- - [Configuration and management](#configuration-and-management)
- - [Warmboot and Fastboot Design Impact](#warmboot-and-fastboot-design-impact)
- - [Restrictions/Limitations](#restrictionslimitations)
- - [Testing Requirements/Design](#testing-requirementsdesign)
- - [Unit Test cases](#unit-test-cases)
- - [System Test cases](#system-test-cases)
-
-### Revision
-
-| Rev | Date | Author | Change Description |
-|:---:|:--------:|:---------------------------:|--------------------|
-| 0.1 |23/Feb/23 | Rajesh Perumal **(Marvell)**| Initial Version |
-
-### Scope
-
-This document provides the high level design for WRED and ECN Statistics in SONiC
-
-### Abbreviations
-
-
-
-| Abbreviation | Description |
-|:-------------:|---------------------------------|
-| __ECN__ | Explicit Congestion Notification|
-| __WRED__ | Weighted Random Early Detection |
-| __CLI__ | Command Line interface |
-| __SAI__ | Switch Abstraction Interface |
-
-
-### Overview
-
-The main goal of this feature is to provide better WRED impact visibility in SONiC by providing a mechanism to count the packets that are dropped or ECN-marked due to WRED.
-
-The other goal of this feature is to display these statistics only if the underlying platform supports it. [CLI changes](#cli-changes) section explains this in detail. Every platform may have unique statistics capabilities, and they change over time, and so it is important for this feature to be capability based.
-
-We will accomplish both the goals by adding statistics support for per-queue WRED dropped packets/bytes, per-queue ECN marked packets/bytes and per-port WRED dropped packets. Existing “show interface counters detailed” CLI will be enhanced for displaying the port level WRED statistics. New CLI will be introduced for queue level WRED and ECN statistics.
-
-In this document, we will be using the term "WRED and ECN statistics" for combined statistics of per-queue WRED dropped packets/bytes, per-queue ECN marked packets/bytes and per-port WRED dropped packets.
-
-### Requirements
-
-1. Support per-queue total ECN marked packets counters(ECN marked in the local switch)
-2. Support per-queue total ECN marked byte counters(ECN marked in the local switch)
-3. Support per-queue total WRED dropped packets counters
-4. Support per-queue total WRED dropped byte counters
-5. Support per-port WRED dropped packets counters (per-color and total count)
-6. Support per-port total ECN marked packets(in the local switch) counters [to be supported in the next phase of enhancement]
-7. Support configuration control to enable and disable the above statistics
-8. Non-supported platforms will not display these statistics on CLI
-
-
-### Architecture Design
-
-There are no architectural design changes as part of this design.
-
-### High-Level Design
-
-This section covers the high level design of the WRED and ECN statistics feature. The following step-by-step short description provides an overview of the operations involved in this feature,
-
-1. Orchagent fetches the platform statistics capability for WRED and ECN Statistics from SAI
-2. The stats capability will be updated to STATE_DB by orchagent
-3. Based on the stats capability and CONFIG_DB status of respective statistics, Orchagent sets stat-ids to FLEX_COUNTERS_DB
- * In case, the platform is capable of WRED and ECN statistics,
- * Per-queue WRED and ECN counters will create and use the new flexcounter group WRED_ECN_QUEUE
- * Per-port WRED and ECN counters will create and use the new flexcounter group WRED_ECN_PORT
-5. Syncd has subscribed to Flex Counter DB and it will set up flex counters.
-6. Flex counters periodically query platform counters and publishes data to COUNTERS_DB
-7. CLI will look-up the Capability at STATE_DB
-8. Only the supported statistics will be fetched and displayed on the CLI output
-
-#### Changes in CONFIG_DB
-
-CONFIG_DB changes are required to enable and disable these statistics globally. For that purpose, Two new flexcounter groups that poll for WRED and ECN statistics will be added to FLEX_COUNTER_TABLE of CONFIG_DB. Flexcounters WRED_ECN_QUEUE and WRED_ECN_PORT will be added to FLEX_COUNTER_TABLE as shown below,
-
-```
-{
- "FLEX_COUNTER_TABLE": {
- "WRED_ECN_QUEUE": {
- "FLEX_COUNTER_STATUS": "enable",
- "POLL_INTERVAL": "10000"
- },
- "WRED_ECN_PORT": {
- "FLEX_COUNTER_STATUS": "enable",
- "POLL_INTERVAL": "1000"
- },
- }
-}
-```
-
-Default polling intervals for flexcounter groups WRED_ECN_QUEUE and WRED_ECN_PORT are 10000 millisecond and 1000 millisecond respectively. By default these flexcounter groups are disabled for polling.
-
-#### Changes in STATE_DB
-State DB will store information about WRED and ECN statistics support as per the platform capability. Statistics capabilities will be populated during Orchagent startup by checking the platform capability. These capabilities are used in CLI to display only the supported counters to user.
-
-```
-"QUEUE_COUNTER_CAPABILITIES": {
- "WRED_ECN_QUEUE_ECN_MARKED_PKT_COUNTER": {
- "isSupported": "true",
- },
- "WRED_ECN_QUEUE_ECN_MARKED_BYTE_COUNTER": {
- "isSupported": "true",
- },
- "WRED_ECN_QUEUE_WRED_DROPPED_PKT_COUNTER": {
- "isSupported": "true",
- },
- "WRED_ECN_QUEUE_WRED_DROPPED_BYTE_COUNTER": {
- "isSupported": "true",
- },
-}
-
-"PORT_COUNTER_CAPABILITIES": {
- "WRED_ECN_PORT_WRED_GREEN_DROP_COUNTER": {
- "isSupported": "true",
- },
- "WRED_ECN_PORT_WRED_YELLOW_DROP_COUNTER": {
- "isSupported": "true",
- },
- "WRED_ECN_PORT_WRED_RED_DROP_COUNTER": {
- "isSupported": "true",
- },
- "WRED_ECN_PORT_WRED_TOTAL_DROP_COUNTER": {
- "isSupported": "true",
- },
-}
-
-```
-
-The default capability will be isSupported=false for all the above statistics.
-
-#### Changes in FLEX_COUNTER_DB
-
-The flexcounter groups need to be created for polling the required statistics. Two new flex counter groups will be introduced for this feature. These are created during Orchagent startup.
-
-On supported platforms,
-* The WRED and ECN queue counters will use the new flexcounter group WRED_ECN_QUEUE for following list of counters,
- * SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS
- * SAI_QUEUE_STAT_WRED_ECN_MARKED_BYTES
- * SAI_QUEUE_STAT_WRED_DROPPED_PACKETS
- * SAI_QUEUE_STAT_WRED_DROPPED_BYTES
-
-* The WRED port counters will use the new flex counter group WRED_ECN_PORT for following list of counters,
- * SAI_PORT_STAT_GREEN_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_YELLOW_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_RED_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_ECN_MARKED_PACKETS [to be supported in next phase of Enhancement]
-
-
-#### Changes in COUNTERS_DB
-
-The following new port counters will be added along with existing counters on supported platforms
-
-* COUNTERS:oid:port_oid
- * SAI_PORT_STAT_GREEN_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_YELLOW_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_RED_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_ECN_MARKED_PACKETS [to be supported in next phase of Enhancement]
-
-For every egress queue, the following statistics will be added along with existing queue conters on supported platforms
-
-* COUNTERS:oid:queue_oid
- * SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS
- * SAI_QUEUE_STAT_WRED_ECN_MARKED_BYTES
- * SAI_QUEUE_STAT_WRED_DROPPED_PACKETS
- * SAI_QUEUE_STAT_WRED_DROPPED_BYTES
-
-
-### Changes in Orchagent
-Orchagent gets the WRED and ECN statistics capability during the startup and updates the STATE_DB with supported statistics. If a counter is supported, respective capability will be set to true. Otherwise the capability will be set to false. Based on the capability in STATE_DB, FLEXCOUNTER_DB will be updated with supported statistics for polling.
-
-
-
-
-Once the WRED_ECN_QUEUE or WRED_ECN_PORT of FLEX_COUNTER_TABLE is enabled, Orchagent will enable the respective flexcounter group. The following diagram illustrates the same,
-
-
-
-
-If the user enables the WRED and ECN statistics on a platform in which all of the statistics of a flexcounter group are not supported, there will be an error message logged to syslog. For example, assume that none of the Queue-level Wred and ECN statistics are supported on a platform, enabling the same will log a syslog error.
-
-### CLI Changes
-
-There are few new CLIs and new CLI tokens are introduced for this feature. And also the output of existing "show interface counters detailed" CLI would change. The details are illustrated below in this section. The show CLIs will display the WRED and ECN statistics only if the capability is supported by the platform. It gets the capability from STATE_DB and queries only the supported statistics from COUNTERS_DB.
-
-* New CLI tokens are introduced under the existing ```counterpoll``` CLI for enabling and disabling the WRED and ECN statistics polling globally,
- * Enable/Disable the queue level counters : ```counterpoll wredqueue ```
- * Enable/Disable the port level counters : ```counterpoll wredport ```
-* New CLI tokens are introduced under the existing ```counterpoll``` CLI for setting the polling interval of the statistics,
- * Set polling interval for queue level counters: ```counterpoll wredqueue interval ```
- * Set polling interval for port level counters: ```counterpoll wredport interval ```
-
-* Existing ```counterpoll``` CLI can be used to display counter status and polling interval,
- * Display the status of the counters : ```counterpoll show```
-
-* Following new CLIs are introduced for Per-queue WRED and ECN Statistics
- * Statistics are cleared on user request : ```sonic-clear queue wredcounters```
- * Display the statistics on the console : ```show queue wredcounters [interface-name]```
-
-
-* Following existing CLIs are used for Per-port WRED statistics
- * Statistics are cleared on user request : ```sonic-clear counters```
- * Display the statistics on the console : ```show interfaces counters detailed ```
-
-#### CLI output on a WRED and ECN queue statistics supported platform
-
-```
-sonic-dut:~# show queue wredcounters Ethernet16
- Port TxQ WredDrp/pkts WredDrp/bytes EcnMarked/pkts EcnMarked/bytes
----------- ----- -------------- --------------- -------------- ---------------
-Ethernet16 UC0 0 0 0 0
-Ethernet16 UC1 1 120 0 0
-Ethernet16 UC2 0 0 0 0
-Ethernet16 UC3 0 0 0 0
-Ethernet16 UC4 0 0 0 0
-Ethernet16 UC5 0 0 0 0
-Ethernet16 UC6 0 0 0 0
-Ethernet16 UC7 0 0 0 0
-```
-#### CLI output on a platform which supports WRED drop statistics and does not support ECN statistics
-```
-sonic-dut:~# show queue wredcounters Ethernet8
- Port TxQ WredDrp/pkts WredDrp/bytes EcnMarked/pkts EcnMarked/bytes
---------- ----- -------------- --------------- ---------------- -----------------
-Ethernet8 UC0 0 0 N/A N/A
-Ethernet8 UC1 1 120 N/A N/A
-Ethernet8 UC2 0 0 N/A N/A
-Ethernet8 UC3 0 0 N/A N/A
-Ethernet8 UC4 0 0 N/A N/A
-Ethernet8 UC5 0 0 N/A N/A
-Ethernet8 UC6 0 0 N/A N/A
-Ethernet8 UC7 0 0 N/A N/A
-
-```
-#### CLI output on a platform which supports ECN statistics and does not support WRED statistics
-```
-sonic-dut:~# show queue wredcounters Ethernet16
- Port TxQ WredDrp/pkts WredDrp/bytes EcnMarked/pkts EcnMarked/bytes
----------- ----- -------------- --------------- ---------------- -----------------
-Ethernet16 UC0 N/A N/A 0 0
-Ethernet16 UC1 N/A N/A 1 120
-Ethernet16 UC2 N/A N/A 0 0
-Ethernet16 UC3 N/A N/A 0 0
-Ethernet16 UC4 N/A N/A 0 0
-Ethernet16 UC5 N/A N/A 0 0
-Ethernet16 UC6 N/A N/A 0 0
-Ethernet16 UC7 N/A N/A 0 0
-
-```
-#### show interface counters CLI output on a WRED drop statistics supported platform
-```
-root@sonic-dut:~# show interfaces counters detailed Ethernet8
-Packets Received 64 Octets..................... 0
-Packets Received 65-127 Octets................. 2
-Packets Received 128-255 Octets................ 0
-Packets Received 256-511 Octets................ 0
-Packets Received 512-1023 Octets............... 0
-Packets Received 1024-1518 Octets.............. 0
-Packets Received 1519-2047 Octets.............. 0
-Packets Received 2048-4095 Octets.............. 0
-Packets Received 4096-9216 Octets.............. 0
-Packets Received 9217-16383 Octets............. 0
-
-Total Packets Received Without Errors.......... 2
-Unicast Packets Received....................... 0
-Multicast Packets Received..................... 2
-Broadcast Packets Received..................... 0
-
-Jabbers Received............................... N/A
-Fragments Received............................. N/A
-Undersize Received............................. 0
-Overruns Received.............................. 0
-
-Packets Transmitted 64 Octets.................. 32,893
-Packets Transmitted 65-127 Octets.............. 16,449
-Packets Transmitted 128-255 Octets............. 3
-Packets Transmitted 256-511 Octets............. 2,387
-Packets Transmitted 512-1023 Octets............ 0
-Packets Transmitted 1024-1518 Octets........... 0
-Packets Transmitted 1519-2047 Octets........... 0
-Packets Transmitted 2048-4095 Octets........... 0
-Packets Transmitted 4096-9216 Octets........... 0
-Packets Transmitted 9217-16383 Octets.......... 0
-
-Total Packets Transmitted Successfully......... 51,732
-Unicast Packets Transmitted.................... 0
-Multicast Packets Transmitted.................. 18,840
-Broadcast Packets Transmitted.................. 32,892
-Time Since Counters Last Cleared............... None
-
-WRED Green Dropped Packets..................... 1
-WRED Yellow Dropped Packets.................... 3
-WRED RED Dropped Packets....................... 10
-WRED Total Dropped Packets..................... 14
-
-```
-
-#### show interface counters CLI output on a platform which does not support WRED drop statistics
-```
-root@sonic-dut:~# show interfaces counters detailed Ethernet8
-Packets Received 64 Octets..................... 0
-Packets Received 65-127 Octets................. 2
-Packets Received 128-255 Octets................ 0
-Packets Received 256-511 Octets................ 0
-Packets Received 512-1023 Octets............... 0
-Packets Received 1024-1518 Octets.............. 0
-Packets Received 1519-2047 Octets.............. 0
-Packets Received 2048-4095 Octets.............. 0
-Packets Received 4096-9216 Octets.............. 0
-Packets Received 9217-16383 Octets............. 0
-
-Total Packets Received Without Errors.......... 2
-Unicast Packets Received....................... 0
-Multicast Packets Received..................... 2
-Broadcast Packets Received..................... 0
-
-Jabbers Received............................... N/A
-Fragments Received............................. N/A
-Undersize Received............................. 0
-Overruns Received.............................. 0
-
-Packets Transmitted 64 Octets.................. 32,893
-Packets Transmitted 65-127 Octets.............. 16,449
-Packets Transmitted 128-255 Octets............. 3
-Packets Transmitted 256-511 Octets............. 2,387
-Packets Transmitted 512-1023 Octets............ 0
-Packets Transmitted 1024-1518 Octets........... 0
-Packets Transmitted 1519-2047 Octets........... 0
-Packets Transmitted 2048-4095 Octets........... 0
-Packets Transmitted 4096-9216 Octets........... 0
-Packets Transmitted 9217-16383 Octets.......... 0
-
-Total Packets Transmitted Successfully......... 51,732
-Unicast Packets Transmitted.................... 0
-Multicast Packets Transmitted.................. 18,840
-Broadcast Packets Transmitted.................. 32,892
-Time Since Counters Last Cleared............... None
-```
-
-The "show queue wredcounters" fetches the statistics from COUNTERS_DB and will display to the console based on the capability of the platform. The below sequence diagram logically explains the "show queue wredcounters" interaction among CLI, STATE_DB and COUNTERS_DB for ECN and WRED statistics on supported platform,
-
-
-
-
-The "show interface counters detailed" will follow the same flow as of now for existing statistics. The below sequence diagram explains the "show interface counters detailed" interaction among CLI, STATE_DB and COUNTERS_DB for WRED drop statistics on supported platform,
-
-
-
-
-
-
-### SAI API
-
-Following SAI statistics are used in this feature,
-
-* SAI counters list,
- * SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS
- * SAI_QUEUE_STAT_WRED_ECN_MARKED_BYTES
- * SAI_QUEUE_STAT_WRED_DROPPED_PACKETS
- * SAI_QUEUE_STAT_WRED_DROPPED_BYTES
- * SAI_PORT_STAT_GREEN_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_YELLOW_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_RED_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_WRED_DROPPED_PACKETS
- * SAI_PORT_STAT_ECN_MARKED_PACKETS [to be supported in next phase of Enhancement]
-
-* sai_query_stats_capability() will be used to identify the supported statistics
-
-* For statistics get and clear, existing APIs are used as it is
-
-### Configuration and management
-
-The config CLI commands ```"counterpoll wredqueue "``` and ```"counterpoll wredport "``` will enable and disable the WRED and ECN statistics by interacting with the FLEX_COUNTER_TABLE table of CONFIG_DB.
-
-### Manifest (if the feature is an Application Extension)
-Not applicable?
-
-### CLI/YANG model Enhancements
-The sonic-flex_counter.yang will be updated with new containers to reflect the proposed CONFIG_DB changes as shown below,
-
- {
- container WRED_ECN_QUEUE {
- /* WRED_ECN_QUEUE_FLEX_COUNTER_GROUP */
- leaf FLEX_COUNTER_STATUS {
- type flex_status;
- }
- leaf FLEX_COUNTER_DELAY_STATUS {
- type flex_delay_status;
- }
- leaf POLL_INTERVAL {
- type poll_interval;
- }
- },
- container WRED_ECN_PORT {
- /* WRED_ECN_PORT_FLEX_COUNTER_GROUP */
- leaf FLEX_COUNTER_STATUS {
- type flex_status;
- }
- leaf FLEX_COUNTER_DELAY_STATUS {
- type flex_delay_status;
- }
- leaf POLL_INTERVAL {
- type poll_interval;
- }
- }
- }
-
-
-
-### Warmboot and Fastboot Design Impact
-There are no impact to warmboot or fastboot.
-
-
-### Restrictions/Limitations
-
-* None
-
-### Testing Requirements/Design
-
-#### Unit Test cases
-- On Supported platforms, Verify if the queuestat CLI display has WRED and ECN Queue statistics
-- On Supported platforms, Verify if the port statistcs CLI display has the WRED statistics
-- On ECN-WRED stats non-supported platforms,
- - Verify that CLI does not show the respective Headers in queue stats
- - Verify that CLI does not show the respective rows in port stats
- - Verify that the stat capability get is not logging errors to syslog
-
-#### System Test cases
-* New sonic-mgmt(PTF) ecn wred statistics testcase will be created to verify the statistics on supported platforms
+# WRED and ECN Statistics
+
+
+## Table of Contents
+- [WRED and ECN Statistics](#wred-and-ecn-statistics)
+ - [Table of Contents](#table-of-contents)
+ - [Revision](#revision)
+ - [Scope](#scope)
+ - [Abbreviations](#abbreviations)
+ - [Overview](#overview)
+ - [Requirements](#requirements)
+ - [Architecture Design](#architecture-design)
+ - [High-Level Design](#high-level-design)
+ - [Changes in CONFIG_DB](#changes-in-config_db)
+ - [Changes in STATE_DB](#changes-in-state_db)
+ - [Changes in FLEX_COUNTER_DB](#changes-in-flex_counter_db)
+ - [Changes in COUNTERS_DB](#changes-in-counters_db)
+ - [Changes in Orchagent](#changes-in-orchagent)
+ - [CLI Changes](#cli-changes)
+ - [CLI output on a WRED and ECN queue statistics supported platform](#cli-output-on-a-wred-and-ECN-queue-statistics-supported-platform)
+ - [CLI output on a platform which supports WRED drop statistics and does not support ECN statistics](#cli-output-on-a-platform-which-supports-wred-drop-statistics-and-does-not-support-ecn-statistics)
+ - [CLI output on a platform which supports ECN statistics and does not support WRED statistics](#cli-output-on-a-platform-which-supports-ecn-statistics-and-does-not-support-wred-statistics)
+ - [show interface counters CLI output on a WRED drop statistics supported platform](#show-interface-counters-cli-output-on-a-wred-drop-statistics-supported-platform)
+ - [show interface counters on a platform which does not support WRED drop statistics](#show-interface-counters-cli-output-on-a-platform-which-does-not-support-wred-drop-statistics)
+ - [SAI API](#sai-api)
+ - [Configuration and management](#configuration-and-management)
+ - [Warmboot and Fastboot Design Impact](#warmboot-and-fastboot-design-impact)
+ - [Restrictions/Limitations](#restrictionslimitations)
+ - [Testing Requirements/Design](#testing-requirementsdesign)
+ - [Unit Test cases](#unit-test-cases)
+ - [System Test cases](#system-test-cases)
+
+### Revision
+
+| Rev | Date | Author | Change Description |
+|:---:|:--------:|:---------------------------:|--------------------|
+| 0.1 |23/Feb/23 | Rajesh Perumal **(Marvell)**| Initial Version |
+
+### Scope
+
+This document provides the high level design for WRED and ECN Statistics in SONiC
+
+### Abbreviations
+
+
+
+| Abbreviation | Description |
+|:-------------:|---------------------------------|
+| __ECN__ | Explicit Congestion Notification|
+| __WRED__ | Weighted Random Early Detection |
+| __CLI__ | Command Line interface |
+| __SAI__ | Switch Abstraction Interface |
+
+
+### Overview
+
+The main goal of this feature is to provide better WRED impact visibility in SONiC by providing a mechanism to count the packets that are dropped or ECN-marked due to WRED.
+
+The other goal of this feature is to display these statistics only if the underlying platform supports it. [CLI changes](#cli-changes) section explains this in detail. Every platform may have unique statistics capabilities, and they change over time, and so it is important for this feature to be capability based.
+
+We will accomplish both the goals by adding statistics support for per-queue WRED dropped packets/bytes, per-queue ECN marked packets/bytes and per-port WRED dropped packets. Existing “show interface counters detailed” CLI will be enhanced for displaying the port level WRED statistics. New CLI will be introduced for queue level WRED and ECN statistics.
+
+In this document, we will be using the term "WRED and ECN statistics" for combined statistics of per-queue WRED dropped packets/bytes, per-queue ECN marked packets/bytes and per-port WRED dropped packets.
+
+### Requirements
+
+1. Support per-queue total ECN marked packets counters(ECN marked in the local switch)
+2. Support per-queue total ECN marked byte counters(ECN marked in the local switch)
+3. Support per-queue total WRED dropped packets counters
+4. Support per-queue total WRED dropped byte counters
+5. Support per-port WRED dropped packets counters (per-color and total count)
+6. Support per-port total ECN marked packets(in the local switch) counters [to be supported in the next phase of enhancement]
+7. Support configuration control to enable and disable the above statistics
+8. Non-supported platforms will not display these statistics on CLI
+
+
+### Architecture Design
+
+There are no architectural design changes as part of this design.
+
+### High-Level Design
+
+This section covers the high level design of the WRED and ECN statistics feature. The following step-by-step short description provides an overview of the operations involved in this feature,
+
+1. Orchagent fetches the platform statistics capability for WRED and ECN Statistics from SAI
+2. The stats capability will be updated to STATE_DB by orchagent
+3. Based on the stats capability and CONFIG_DB status of respective statistics, Orchagent sets stat-ids to FLEX_COUNTERS_DB
+ * In case, the platform is capable of WRED and ECN statistics,
+ * Per-queue WRED and ECN counters will create and use the new flexcounter group WRED_ECN_QUEUE
+ * Per-port WRED and ECN counters will create and use the new flexcounter group WRED_ECN_PORT
+5. Syncd has subscribed to Flex Counter DB and it will set up flex counters.
+6. Flex counters periodically query platform counters and publishes data to COUNTERS_DB
+7. CLI will look-up the Capability at STATE_DB
+8. Only the supported statistics will be fetched and displayed on the CLI output
+
+#### Changes in CONFIG_DB
+
+CONFIG_DB changes are required to enable and disable these statistics globally. For that purpose, Two new flexcounter groups that poll for WRED and ECN statistics will be added to FLEX_COUNTER_TABLE of CONFIG_DB. Flexcounters WRED_ECN_QUEUE and WRED_ECN_PORT will be added to FLEX_COUNTER_TABLE as shown below,
+
+```
+{
+ "FLEX_COUNTER_TABLE": {
+ "WRED_ECN_QUEUE": {
+ "FLEX_COUNTER_STATUS": "enable",
+ "POLL_INTERVAL": "10000"
+ },
+ "WRED_ECN_PORT": {
+ "FLEX_COUNTER_STATUS": "enable",
+ "POLL_INTERVAL": "1000"
+ },
+ }
+}
+```
+
+Default polling intervals for flexcounter groups WRED_ECN_QUEUE and WRED_ECN_PORT are 10000 millisecond and 1000 millisecond respectively. By default these flexcounter groups are disabled for polling.
+
+#### Changes in STATE_DB
+State DB will store information about WRED and ECN statistics support as per the platform capability. Statistics capabilities will be populated during Orchagent startup by checking the platform capability. These capabilities are used in CLI to display only the supported counters to user.
+
+```
+"QUEUE_COUNTER_CAPABILITIES": {
+ "WRED_ECN_QUEUE_ECN_MARKED_PKT_COUNTER": {
+ "isSupported": "true",
+ },
+ "WRED_ECN_QUEUE_ECN_MARKED_BYTE_COUNTER": {
+ "isSupported": "true",
+ },
+ "WRED_ECN_QUEUE_WRED_DROPPED_PKT_COUNTER": {
+ "isSupported": "true",
+ },
+ "WRED_ECN_QUEUE_WRED_DROPPED_BYTE_COUNTER": {
+ "isSupported": "true",
+ },
+}
+
+"PORT_COUNTER_CAPABILITIES": {
+ "WRED_ECN_PORT_WRED_GREEN_DROP_COUNTER": {
+ "isSupported": "true",
+ },
+ "WRED_ECN_PORT_WRED_YELLOW_DROP_COUNTER": {
+ "isSupported": "true",
+ },
+ "WRED_ECN_PORT_WRED_RED_DROP_COUNTER": {
+ "isSupported": "true",
+ },
+ "WRED_ECN_PORT_WRED_TOTAL_DROP_COUNTER": {
+ "isSupported": "true",
+ },
+}
+
+```
+
+The default capability will be isSupported=false for all the above statistics.
+
+#### Changes in FLEX_COUNTER_DB
+
+The flexcounter groups need to be created for polling the required statistics. Two new flex counter groups will be introduced for this feature. These are created during Orchagent startup.
+
+On supported platforms,
+* The WRED and ECN queue counters will use the new flexcounter group WRED_ECN_QUEUE for following list of counters,
+ * SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS
+ * SAI_QUEUE_STAT_WRED_ECN_MARKED_BYTES
+ * SAI_QUEUE_STAT_WRED_DROPPED_PACKETS
+ * SAI_QUEUE_STAT_WRED_DROPPED_BYTES
+
+* The WRED port counters will use the new flex counter group WRED_ECN_PORT for following list of counters,
+ * SAI_PORT_STAT_GREEN_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_YELLOW_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_RED_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_ECN_MARKED_PACKETS [to be supported in next phase of Enhancement]
+
+
+#### Changes in COUNTERS_DB
+
+The following new port counters will be added along with existing counters on supported platforms
+
+* COUNTERS:oid:port_oid
+ * SAI_PORT_STAT_GREEN_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_YELLOW_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_RED_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_ECN_MARKED_PACKETS [to be supported in next phase of Enhancement]
+
+For every egress queue, the following statistics will be added along with existing queue counters on supported platforms
+
+* COUNTERS:oid:queue_oid
+ * SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS
+ * SAI_QUEUE_STAT_WRED_ECN_MARKED_BYTES
+ * SAI_QUEUE_STAT_WRED_DROPPED_PACKETS
+ * SAI_QUEUE_STAT_WRED_DROPPED_BYTES
+
+
+### Changes in Orchagent
+Orchagent gets the WRED and ECN statistics capability during the startup and updates the STATE_DB with supported statistics. If a counter is supported, respective capability will be set to true. Otherwise the capability will be set to false. Based on the capability in STATE_DB, FLEXCOUNTER_DB will be updated with supported statistics for polling.
+
+
+
+
+Once the WRED_ECN_QUEUE or WRED_ECN_PORT of FLEX_COUNTER_TABLE is enabled, Orchagent will enable the respective flexcounter group. The following diagram illustrates the same,
+
+
+
+
+If the user enables the WRED and ECN statistics on a platform in which all of the statistics of a flexcounter group are not supported, there will be an error message logged to syslog. For example, assume that none of the Queue-level Wred and ECN statistics are supported on a platform, enabling the same will log a syslog error.
+
+### CLI Changes
+
+There are few new CLIs and new CLI tokens are introduced for this feature. And also the output of existing "show interface counters detailed" CLI would change. The details are illustrated below in this section. The show CLIs will display the WRED and ECN statistics only if the capability is supported by the platform. It gets the capability from STATE_DB and queries only the supported statistics from COUNTERS_DB.
+
+* New CLI tokens are introduced under the existing ```counterpoll``` CLI for enabling and disabling the WRED and ECN statistics polling globally,
+ * Enable/Disable the queue level counters : ```counterpoll wredqueue ```
+ * Enable/Disable the port level counters : ```counterpoll wredport ```
+* New CLI tokens are introduced under the existing ```counterpoll``` CLI for setting the polling interval of the statistics,
+ * Set polling interval for queue level counters: ```counterpoll wredqueue interval ```
+ * Set polling interval for port level counters: ```counterpoll wredport interval ```
+
+* Existing ```counterpoll``` CLI can be used to display counter status and polling interval,
+ * Display the status of the counters : ```counterpoll show```
+
+* Following new CLIs are introduced for Per-queue WRED and ECN Statistics
+ * Statistics are cleared on user request : ```sonic-clear queue wredcounters```
+ * Display the statistics on the console : ```show queue wredcounters [interface-name]```
+
+
+* Following existing CLIs are used for Per-port WRED statistics
+ * Statistics are cleared on user request : ```sonic-clear counters```
+ * Display the statistics on the console : ```show interfaces counters detailed ```
+
+#### CLI output on a WRED and ECN queue statistics supported platform
+
+```
+sonic-dut:~# show queue wredcounters Ethernet16
+ Port TxQ WredDrp/pkts WredDrp/bytes EcnMarked/pkts EcnMarked/bytes
+---------- ----- -------------- --------------- -------------- ---------------
+Ethernet16 UC0 0 0 0 0
+Ethernet16 UC1 1 120 0 0
+Ethernet16 UC2 0 0 0 0
+Ethernet16 UC3 0 0 0 0
+Ethernet16 UC4 0 0 0 0
+Ethernet16 UC5 0 0 0 0
+Ethernet16 UC6 0 0 0 0
+Ethernet16 UC7 0 0 0 0
+```
+#### CLI output on a platform which supports WRED drop statistics and does not support ECN statistics
+```
+sonic-dut:~# show queue wredcounters Ethernet8
+ Port TxQ WredDrp/pkts WredDrp/bytes EcnMarked/pkts EcnMarked/bytes
+--------- ----- -------------- --------------- ---------------- -----------------
+Ethernet8 UC0 0 0 N/A N/A
+Ethernet8 UC1 1 120 N/A N/A
+Ethernet8 UC2 0 0 N/A N/A
+Ethernet8 UC3 0 0 N/A N/A
+Ethernet8 UC4 0 0 N/A N/A
+Ethernet8 UC5 0 0 N/A N/A
+Ethernet8 UC6 0 0 N/A N/A
+Ethernet8 UC7 0 0 N/A N/A
+
+```
+#### CLI output on a platform which supports ECN statistics and does not support WRED statistics
+```
+sonic-dut:~# show queue wredcounters Ethernet16
+ Port TxQ WredDrp/pkts WredDrp/bytes EcnMarked/pkts EcnMarked/bytes
+---------- ----- -------------- --------------- ---------------- -----------------
+Ethernet16 UC0 N/A N/A 0 0
+Ethernet16 UC1 N/A N/A 1 120
+Ethernet16 UC2 N/A N/A 0 0
+Ethernet16 UC3 N/A N/A 0 0
+Ethernet16 UC4 N/A N/A 0 0
+Ethernet16 UC5 N/A N/A 0 0
+Ethernet16 UC6 N/A N/A 0 0
+Ethernet16 UC7 N/A N/A 0 0
+
+```
+#### show interface counters CLI output on a WRED drop statistics supported platform
+```
+root@sonic-dut:~# show interfaces counters detailed Ethernet8
+Packets Received 64 Octets..................... 0
+Packets Received 65-127 Octets................. 2
+Packets Received 128-255 Octets................ 0
+Packets Received 256-511 Octets................ 0
+Packets Received 512-1023 Octets............... 0
+Packets Received 1024-1518 Octets.............. 0
+Packets Received 1519-2047 Octets.............. 0
+Packets Received 2048-4095 Octets.............. 0
+Packets Received 4096-9216 Octets.............. 0
+Packets Received 9217-16383 Octets............. 0
+
+Total Packets Received Without Errors.......... 2
+Unicast Packets Received....................... 0
+Multicast Packets Received..................... 2
+Broadcast Packets Received..................... 0
+
+Jabbers Received............................... N/A
+Fragments Received............................. N/A
+Undersize Received............................. 0
+Overruns Received.............................. 0
+
+Packets Transmitted 64 Octets.................. 32,893
+Packets Transmitted 65-127 Octets.............. 16,449
+Packets Transmitted 128-255 Octets............. 3
+Packets Transmitted 256-511 Octets............. 2,387
+Packets Transmitted 512-1023 Octets............ 0
+Packets Transmitted 1024-1518 Octets........... 0
+Packets Transmitted 1519-2047 Octets........... 0
+Packets Transmitted 2048-4095 Octets........... 0
+Packets Transmitted 4096-9216 Octets........... 0
+Packets Transmitted 9217-16383 Octets.......... 0
+
+Total Packets Transmitted Successfully......... 51,732
+Unicast Packets Transmitted.................... 0
+Multicast Packets Transmitted.................. 18,840
+Broadcast Packets Transmitted.................. 32,892
+Time Since Counters Last Cleared............... None
+
+WRED Green Dropped Packets..................... 1
+WRED Yellow Dropped Packets.................... 3
+WRED RED Dropped Packets....................... 10
+WRED Total Dropped Packets..................... 14
+
+```
+
+#### show interface counters CLI output on a platform which does not support WRED drop statistics
+```
+root@sonic-dut:~# show interfaces counters detailed Ethernet8
+Packets Received 64 Octets..................... 0
+Packets Received 65-127 Octets................. 2
+Packets Received 128-255 Octets................ 0
+Packets Received 256-511 Octets................ 0
+Packets Received 512-1023 Octets............... 0
+Packets Received 1024-1518 Octets.............. 0
+Packets Received 1519-2047 Octets.............. 0
+Packets Received 2048-4095 Octets.............. 0
+Packets Received 4096-9216 Octets.............. 0
+Packets Received 9217-16383 Octets............. 0
+
+Total Packets Received Without Errors.......... 2
+Unicast Packets Received....................... 0
+Multicast Packets Received..................... 2
+Broadcast Packets Received..................... 0
+
+Jabbers Received............................... N/A
+Fragments Received............................. N/A
+Undersize Received............................. 0
+Overruns Received.............................. 0
+
+Packets Transmitted 64 Octets.................. 32,893
+Packets Transmitted 65-127 Octets.............. 16,449
+Packets Transmitted 128-255 Octets............. 3
+Packets Transmitted 256-511 Octets............. 2,387
+Packets Transmitted 512-1023 Octets............ 0
+Packets Transmitted 1024-1518 Octets........... 0
+Packets Transmitted 1519-2047 Octets........... 0
+Packets Transmitted 2048-4095 Octets........... 0
+Packets Transmitted 4096-9216 Octets........... 0
+Packets Transmitted 9217-16383 Octets.......... 0
+
+Total Packets Transmitted Successfully......... 51,732
+Unicast Packets Transmitted.................... 0
+Multicast Packets Transmitted.................. 18,840
+Broadcast Packets Transmitted.................. 32,892
+Time Since Counters Last Cleared............... None
+```
+
+The "show queue wredcounters" fetches the statistics from COUNTERS_DB and will display to the console based on the capability of the platform. The below sequence diagram logically explains the "show queue wredcounters" interaction among CLI, STATE_DB and COUNTERS_DB for ECN and WRED statistics on supported platform,
+
+
+
+
+The "show interface counters detailed" will follow the same flow as of now for existing statistics. The below sequence diagram explains the "show interface counters detailed" interaction among CLI, STATE_DB and COUNTERS_DB for WRED drop statistics on supported platform,
+
+
+
+
+
+
+### SAI API
+
+Following SAI statistics are used in this feature,
+
+* SAI counters list,
+ * SAI_QUEUE_STAT_WRED_ECN_MARKED_PACKETS
+ * SAI_QUEUE_STAT_WRED_ECN_MARKED_BYTES
+ * SAI_QUEUE_STAT_WRED_DROPPED_PACKETS
+ * SAI_QUEUE_STAT_WRED_DROPPED_BYTES
+ * SAI_PORT_STAT_GREEN_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_YELLOW_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_RED_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_WRED_DROPPED_PACKETS
+ * SAI_PORT_STAT_ECN_MARKED_PACKETS [to be supported in next phase of Enhancement]
+
+* sai_query_stats_capability() will be used to identify the supported statistics
+
+* For statistics get and clear, existing APIs are used as it is
+
+### Configuration and management
+
+The config CLI commands ```"counterpoll wredqueue "``` and ```"counterpoll wredport "``` will enable and disable the WRED and ECN statistics by interacting with the FLEX_COUNTER_TABLE table of CONFIG_DB.
+
+### Manifest (if the feature is an Application Extension)
+Not applicable?
+
+### CLI/YANG model Enhancements
+The sonic-flex_counter.yang will be updated with new containers to reflect the proposed CONFIG_DB changes as shown below,
+
+ {
+ container WRED_ECN_QUEUE {
+ /* WRED_ECN_QUEUE_FLEX_COUNTER_GROUP */
+ leaf FLEX_COUNTER_STATUS {
+ type flex_status;
+ }
+ leaf FLEX_COUNTER_DELAY_STATUS {
+ type flex_delay_status;
+ }
+ leaf POLL_INTERVAL {
+ type poll_interval;
+ }
+ },
+ container WRED_ECN_PORT {
+ /* WRED_ECN_PORT_FLEX_COUNTER_GROUP */
+ leaf FLEX_COUNTER_STATUS {
+ type flex_status;
+ }
+ leaf FLEX_COUNTER_DELAY_STATUS {
+ type flex_delay_status;
+ }
+ leaf POLL_INTERVAL {
+ type poll_interval;
+ }
+ }
+ }
+
+
+
+### Warmboot and Fastboot Design Impact
+There are no impact to warmboot or fastboot.
+
+
+### Restrictions/Limitations
+
+* None
+
+### Testing Requirements/Design
+
+#### Unit Test cases
+- On Supported platforms, Verify if the queuestat CLI display has WRED and ECN Queue statistics
+- On Supported platforms, Verify if the port statistics CLI display has the WRED statistics
+- On ECN-WRED stats non-supported platforms,
+ - Verify that CLI does not show the respective Headers in queue stats
+ - Verify that CLI does not show the respective rows in port stats
+ - Verify that the stat capability get is not logging errors to syslog
+
+#### System Test cases
+* New sonic-mgmt(PTF) ecn wred statistics testcase will be created to verify the statistics on supported platforms
diff --git a/doc/qos/dynamically-headroom-calculation.md b/doc/qos/dynamically-headroom-calculation.md
index a52e186da01..da1e76ccb81 100644
--- a/doc/qos/dynamically-headroom-calculation.md
+++ b/doc/qos/dynamically-headroom-calculation.md
@@ -18,7 +18,7 @@ Currently, the headroom size is generated by looking up the port's cable length
Currently the headroom buffer calculation is done by looking up the `pg_profile_lookup.ini` table with the ports' cable length and speed as the key.
- When system starts, it reads the pg_profile_lookup.ini and generates an internal lookup table indexed by speed and cable length, and containing size, xon, xoff and threshold.
-- When a port's cable length updated, it records the cable length of the port. But it doesn't update relavent tables accordingly.
+- When a port's cable length updated, it records the cable length of the port. But it doesn't update relevant tables accordingly.
- When a port's speed updated,
1. It looks up the (speed, cable length) tuple in the BUFFER_PROFILE table or generate a new profile according to the internal lookup table.
2. And then update the port's BUFFER_PG table for the lossless priority group.
@@ -26,7 +26,7 @@ Currently the headroom buffer calculation is done by looking up the `pg_profile_
There are some limitations:
- The `pg_profile_lookup.ini` is predefined for each SKU. When a new system supports SONiC the file should be provided accordingly.
-- Only a fixed set of cable lengths are supproted.
+- Only a fixed set of cable lengths are supported.
- Static headroom isn't supported.
In general, we would like to:
@@ -43,7 +43,7 @@ We will have the following groups of parameters
- List of SONiC configuration, such as speed and cable length.
- List of ASIC related configuration, such as cell size, MAC/PHY delay, peer response time, IPG.
-- List of PERIPHERIAL related configuration, such as gearbox delay.
+- List of PERIPHERAL related configuration, such as gearbox delay.
- List of lossless traffic related configuration, such as MTU, small packet size percentage.
Based on the parameters and a well-known formula the code in buffer manager will do the calculation and not take it from a pre-defined values as we have today.
@@ -75,7 +75,7 @@ Even though the shared buffer concept is defined by the SAI which is generic, ea
- when a port's headroom is updated, the size of ingress buffer pool doesn't need to be updated.
- different ways in which xon/xoff packet is triggered:
- When the available (headroom) buffer of a PG becomes less than `xoff` threshold, the xoff packet will be generated. `xoff` threshold will be calculated by the well-known formula.
- - If `xon_offset` of `BUFFER_PROFILE` is defined, the xon packet will be generated if the availabe buffer of a PG becomes greater than `BUFFER_POOL.size` - `BUFFER_PROFILE.xon_offset` or `BUFFER_PROFILE.xon` which is larger. Otherwise, only `BUFFER_PROFILE.xon` is taken into consideration when triggering xon packet.
+ - If `xon_offset` of `BUFFER_PROFILE` is defined, the xon packet will be generated if the available buffer of a PG becomes greater than `BUFFER_POOL.size` - `BUFFER_PROFILE.xon_offset` or `BUFFER_PROFILE.xon` which is larger. Otherwise, only `BUFFER_PROFILE.xon` is taken into consideration when triggering xon packet.
All the above difference will be reflected to the parameters dynamically calculated. As a result, the following things can be vendor-specific:
@@ -103,7 +103,7 @@ To tolerance that difference, we will introduce lua plugins. The idea is:
- The dynamic headroom calculation will be enabled when SONiC switch is upgraded from the old image to the image supporting dynamic calculation if all the buffer configuration aligns the default value. In this case, a port's headroom size of all the lossless priority groups will be calculated. The shared buffer pool will be adjusted according to the headroom size if they're the default value in the old image.
- The dynamic headroom calculation will be disabled when SONiC switch is configured via executing `config load_minigraph`. In this case, the traditional look-up model will be applied.
-- When a port's cable length, speed or MTU is updated, headroom of all lossless priority groups will be updated according to the well-known formula and then programed to ASIC.
+- When a port's cable length, speed or MTU is updated, headroom of all lossless priority groups will be updated according to the well-known formula and then programmed to ASIC.
- When a port is shut down/started up or its headroom size is updated, the size of shared buffer pool will be adjusted accordingly. The less the headroom, the more the shared buffer and vice versa. By doing so, we are able to have as much shared buffer as possible.
- Pre-defined `pg_profile_lookup.ini` isn't required any more. When a new platform supports SONiC only a few parameters are required.
- Support arbitrary cable length.
@@ -173,13 +173,13 @@ SAI_PORT_ATTR_MAXIMUM_HEADROOM_SIZE, which returns the maximum accumulative head
## Data schema design
-The data schema design will be introduced in this section. Redis database tables releated to dynamically calculation will be introduced in this section. Hardware related parameters which are not saved in the database will also be introduced as they have a table-like organization which is similiar as database.
+The data schema design will be introduced in this section. Redis database tables related to dynamically calculation will be introduced in this section. Hardware related parameters which are not saved in the database will also be introduced as they have a table-like organization which is similar as database.
1. The following tables contain hardware related information and will be initialized by loading json files and stored in `STATE_DB`:
- `ASIC_TABLE` where the ASIC related parameters are stored.
- `PERIPHERAL_TABLE` where the peripheral model parameters are stored, like gearbox.
- `PORT_PERIPHERAL_TABLE` where the per-port peripheral model are stored.
- - `BUFFER_MAX_PARAM` where the maxinum of some parameters regarding buffer are stored.
+ - `BUFFER_MAX_PARAM` where the maximum of some parameters regarding buffer are stored.
2. The following tables are newly introduced and stored in `CONFIG_DB`, including:
- `LOSSLESS_TRAFFIC_PATTERN` where the traffic pattern related parameters are stored.
- `LOSSLESS_BUFFER_PARAM` where the default parameters used to generate `BUFFER_PROFILE` for lossless traffic is stored.
@@ -371,8 +371,8 @@ The key should be switch chip model name in captical letters.
```schema
key = BUFFER_MAX_PARAM| ; when key is global, it should contain mmu_size.
; when key is port name, it should contain max_headroom_size.
- mmu_size = 1*9DIGIT ; Total avaiable memory a buffer pool can occupy
- max_headroom_size = 1*6DIGIT ; Optional. The maxinum value of headroom size a physical port can have.
+ mmu_size = 1*9DIGIT ; Total available memory a buffer pool can occupy
+ max_headroom_size = 1*6DIGIT ; Optional. The maximum value of headroom size a physical port can have.
; The accumulative headroom size of a port should be less than this threshold.
; Not providing this field means no such limitation for the ASIC.
```
@@ -450,7 +450,7 @@ Currently, there already are some fields in `BUFFER_POOL` table. In this design,
mode = "static" / "dynamic" ; indicating the pool's threshold mode
size = 1*9DIGIT ; the size of the pool. It exists only when the pool size is static.
; For a pool whose size needs to be updated dynamically, the size should be omitted in this table
- ; and its real size will be calculated by substracting accumulative headroom and reserved size
+ ; and its real size will be calculated by subtracting accumulative headroom and reserved size
; from total available memory which stored ASIC_TABLE.
xoff = 1*9DIGIT ; the shared headroom pool size. Available for ingress_lossless_pool only.
percentage = 1*3DIGIT ; the percentage of the buffer pool size compared with the whole available memory size
@@ -460,7 +460,7 @@ Currently, there already are some fields in `BUFFER_POOL` table. In this design,
##### Initialization
-Typically there are the following entries defined in `/usr/shared/sonic/device///buffers.json.j2` by all vendors.
+Typically there are the following entries defined in `/usr/shared/sonic/device///buffers.json.j2` by all vendors.
- ingress_lossless_pool
- ingress_lossy_pool
@@ -477,7 +477,7 @@ Table `BUFFER_PROFILE` contains the profiles of headroom parameters and the prop
##### Schema
-Currently, there already are some fields in `BUFFER_PROFILE` table. In this design, the field `headroom_type` is newly introduced, indicating whether the headroom information, including `xon`, `xoff` and `size`, are dynamically calculated based on the `speed` and `cable length` of the port. Accordingly, the fileds `xon`, `xoff` and `size` only exist when the `headroom_type` is `static`.
+Currently, there already are some fields in `BUFFER_PROFILE` table. In this design, the field `headroom_type` is newly introduced, indicating whether the headroom information, including `xon`, `xoff` and `size`, are dynamically calculated based on the `speed` and `cable length` of the port. Accordingly, the fields `xon`, `xoff` and `size` only exist when the `headroom_type` is `static`.
```schema
key = BUFFER_PROFILE|
@@ -499,7 +499,7 @@ The profile is configured by CLI.
##### Initialization
-Typically there are the following entries defined in `/usr/shared/sonic/device///buffers.json.j2` by all vendors.
+Typically there are the following entries defined in `/usr/shared/sonic/device///buffers.json.j2` by all vendors.
- ingress_lossless_profile
- ingress_lossy_profile
@@ -512,7 +512,7 @@ The initialization of the above entries is the same as that of `BUFFER_PROFILE`
Besides the above entries, there are the following ones which will be generated on-the-fly:
1. Headroom override entries for lossless traffic, which will be configured by user.
-2. Entries for ingress loessless traffic with specific cable length, speed and MTU. They will be referenced by `BUFFER_PG` table and created if there is no such entry corresponding to a newly occuring `speed` and `cable length` tuple. The name convention should be `pg_lossless__[_mtu][_th]_profile`.
+2. Entries for ingress loessless traffic with specific cable length, speed and MTU. They will be referenced by `BUFFER_PG` table and created if there is no such entry corresponding to a newly occurring `speed` and `cable length` tuple. The name convention should be `pg_lossless__[_mtu][_th]_profile`.
- The `[_mtu]` part only exists when the port's MTU isn't the default value.
- The `[_th]` part only exists when the dynamic_th isn't the default value.
3. On top of 2, on platforms who have different gearbox models among ports, the gearbox model should also be reflected in the profile. In this case, even though two ports share the same speed and cable length, they need to adopt different profile if their gearbox model isn't same. The name convention should be `pg_lossless___[mtu]__profile`.
@@ -844,7 +844,7 @@ An exception is warm reboot. During warm reboot the headroom is updated for each
To achieve that, the buffer pool shouldn't be updated during warm reboot and will be updated once warm reboot finished.
-The avaliable buffer pool size euqals to the maxinum avaliable buffer pool size minus the accumulative size of buffer reserved for port and (port, PG) in ingress and (port, queue) in egress. The algorithm is as below:
+The available buffer pool size equals to the maximum available buffer pool size minus the accumulative size of buffer reserved for port and (port, PG) in ingress and (port, queue) in egress. The algorithm is as below:
1. Accumulate all headroom by iterating all `port`, `priority group` tuple and `port`, `queue` tuple and putting their `size` together.
2. Accumulate all reserved buffer for egress traffic for all ports.
@@ -876,7 +876,7 @@ __Figure 5: Cable length or speed updated__
#### Port is administratively up/down
-When a port's administratively status is changed, the `BUFFER_PG` of administratively down port will be removed and the sum of effective headroom size will be udpated accordingly, hense the `BUFFER_POOL` should be updated.
+When a port's administratively status is changed, the `BUFFER_PG` of administratively down port will be removed and the sum of effective headroom size will be updated accordingly, hence the `BUFFER_POOL` should be updated.
#### Configure additional lossless PGs on a port
@@ -1017,10 +1017,10 @@ sonic#config buffer profile set --xon --xoff --size -
sonic#config buffer profile remove
```
-All the parameters are devided to two groups, one for headroom and one for dynamic_th. For any command at lease one group of parameters should be provided.
+All the parameters are divided to two groups, one for headroom and one for dynamic_th. For any command at lease one group of parameters should be provided.
For headroom parameters:
-- `xon` is madantory.
+- `xon` is mandatory.
- If shared headroom pool is disabled:
- At lease one of `xoff` and `size` should be provided and the other will be optional and deduced via the formula `xon + xoff = size`.
All other parameters are mandatory.
@@ -1440,11 +1440,11 @@ In APPL_DB there should be:
Status: Closed.
Decision: Yes. They should be taken into consideration.
-7. There is limitations from SDK/FW that there is a cap of the total number of headroom sizes of all priority groups belong to a port. For 2700 split port, this cap prevent the headroom size from being programed if the speed is 50G and cable length is 300m.
+7. There is limitations from SDK/FW that there is a cap of the total number of headroom sizes of all priority groups belong to a port. For 2700 split port, this cap prevent the headroom size from being programmed if the speed is 50G and cable length is 300m.
Status: Closed.
- Decision: There should be a maxinum value of the accumulate PGs for port. This can be fetched from ASIC_DB.
+ Decision: There should be a maximum value of the accumulate PGs for port. This can be fetched from ASIC_DB.
8. Originally buffer configuration had been stored in APPL_DB but were moved to CONFIG_DB later. Why? [doc](https://github.com/sonic-net/SONiC/wiki/Converting-old-or-creating-new-buffers-config) for reference.
9. In theory, when system starts, as `BUFFER_PROFILE` and `BUFFER_PG` tables are stored in config database which survives system reboot, the `Buffer Orch` can receive items of the tables ahead of they being recalculated by `Buffer Manager` based on the current algorithm and `cable length` and `speed`. If the headroom size calculated differs before and after reboot, it can cause the items in the tables be deployed twice in which the first deployment will be overwritten quickly by the second one.
10. For chassis systems the gearbox in variant line-cards can differ, which means a mapping from port/line-card to gearbox model is required to get the correct gearbox model for a port. This requires additional field defined in `PORT` table or some newly introduced table. As this part hasn't been defined in community, we will not discuss this case for now.
@@ -1461,12 +1461,12 @@ In APPL_DB there should be:
- independent: headroom is for PG/port only and isn't shared among PGs or ports.
- shared in port level: headroom is for PG/port and shared among PGs belonging the same port:
- which `xoff` indicates the memory reservation and which for threshold?
- - threshold is for trigerring the PFC frames
+ - threshold is for triggering the PFC frames
- memory reservation indicates pool calculation
- How to generate the profile on a port level? oversubscribe ratio?
- shared in system level: headroom is for PG/port and shared among PGs in the system:
- Buffer pool's `xoff` indicates the memory usage
- - Buffer profile's `xoff` is the threshold of triggerring the PFC frames
+ - Buffer profile's `xoff` is the threshold of triggering the PFC frames
- over subscribe ratio = pool's `xoff` / accumulative PG's `xoff`
6. Support variant way to trigger XON packet
diff --git a/doc/qos/reclaim-reserved-buffer-images/reclaim-reserved-buffer-sequence-flow.md b/doc/qos/reclaim-reserved-buffer-images/reclaim-reserved-buffer-sequence-flow.md
index 9b017e4ff5e..2ff05e1e17e 100644
--- a/doc/qos/reclaim-reserved-buffer-images/reclaim-reserved-buffer-sequence-flow.md
+++ b/doc/qos/reclaim-reserved-buffer-images/reclaim-reserved-buffer-sequence-flow.md
@@ -50,12 +50,12 @@ sequenceDiagram
sonic cfggen ->> DATABASE: Generate BUFFER_QUEUE item for queue 0-2, 3-4, 5-6 for the port
sonic cfggen ->> DATABASE: Generate BUFFER_PORT_INGRESS_PROFILE_LIST item
sonic cfggen ->> DATABASE: Generate BUFFER_PORT_EGRESS_PROFILE_LIST item
- Note over sonic cfggen, DATABASE: Generat lossy PGs by rendering the buffer template if NO special script to generate them
+ Note over sonic cfggen, DATABASE: Generate lossy PGs by rendering the buffer template if NO special script to generate them
sonic cfggen ->> DATABASE: Generate lossy BUFFER_PG item PG 0 for the port, using normal ingress lossy buffer profile
end
rect rgb(255, 0, 255)
opt zero profiles exist
- Note over sonic cfggen, DATABASE: Generate items for inactive ports by rendering bufer template if zero profiles exist
+ Note over sonic cfggen, DATABASE: Generate items for inactive ports by rendering buffer template if zero profiles exist
loop for each inactive port
sonic cfggen ->> DATABASE: Generate zero buffer profile item in BUFFER_QUEUE table for queue 0-7
sonic cfggen ->> DATABASE: Generate zero buffer profile item in BUFFER_PORT_INGRESS_PROFILE_LIST table
diff --git a/doc/qos/reclaim-reserved-buffer.md b/doc/qos/reclaim-reserved-buffer.md
index f2b5df0dbb1..4a362837c5f 100644
--- a/doc/qos/reclaim-reserved-buffer.md
+++ b/doc/qos/reclaim-reserved-buffer.md
@@ -38,7 +38,7 @@ The requirement is to reclaim the reserved buffer for admin down ports, includin
The reserved buffer is reclaimed when the port is admin down. The port can be admin down in the following two scenarios:
1. The port is not used by deployment. In other words, the port is an INACTIVE port.
-2. The port is temporarily shut down for maintaince, for example, to replace a broken cable or module attached on the port.
+2. The port is temporarily shut down for maintenance, for example, to replace a broken cable or module attached on the port.
The buffer reserved for the port is reclaimed in both scenario.
@@ -196,7 +196,7 @@ They need to be moved from the middle of `buffer_template.j2` to the place just
{% endraw %} # ignore this line please
```
-The vairable `port_names_inactive` also need to be generated by the following snipped of code.
+The variable `port_names_inactive` also need to be generated by the following snipped of code.
```json
{% raw %} # ignore this line please
@@ -736,13 +736,13 @@ Currently, there is only one field `max_headroom_size` in the table. The fields
key = BUFFER_MAX_PARAM_TABLE| ; when key is global, it should contain mmu_size.
; when key is port name, it should contain max_headroom_size, max_priority_groups, and max_queues.
; The following keys have been defined in the table currently.
- mmu_size = 1*9DIGIT ; Total avaiable memory a buffer pool can occupy
- max_headroom_size = 1*6DIGIT ; Optional. The maxinum value of headroom size a physical port can have.
+ mmu_size = 1*9DIGIT ; Total available memory a buffer pool can occupy
+ max_headroom_size = 1*6DIGIT ; Optional. The maximum value of headroom size a physical port can have.
; The accumulative headroom size of a port should be less than this threshold.
; Not providing this field means no such limitation for the ASIC.
; The following keys will be introduced in the table for reclaiming reserved buffer
- max_priority_groups = 2*6DIGIT ; The maxinum number of priority groups supported on the port.
- max_queues = 2*6DIGIT ; The maxinum number of queues supported on the port.
+ max_priority_groups = 2*6DIGIT ; The maximum number of priority groups supported on the port.
+ max_queues = 2*6DIGIT ; The maximum number of queues supported on the port.
```
@@ -859,7 +859,7 @@ In the example, the egress_zero_profile is not specified, so the buffer profile
The ports orchagent fetches the maximum numbers of queues and priority groups of a port via SAI interfaces when it is creating the port. After that, it will push the maximum numbers to `STATE_DB.BUFFER_MAX_PARAM_TABLE`.
-The buffer manager listens to the tables. Once it has heard the maximum numbers, it will generage the IDs of all queues and priority groups and store them into its internal data structure. The IDs of all queues and priority groups can be used to apply zero profiles when a port is admin down. In case the buffer manager hasn't heard the maximum numbers of queues or priority groups when a port is shut down, it will mark the port as `pending apply zero profiles` and retry later.
+The buffer manager listens to the tables. Once it has heard the maximum numbers, it will generate the IDs of all queues and priority groups and store them into its internal data structure. The IDs of all queues and priority groups can be used to apply zero profiles when a port is admin down. In case the buffer manager hasn't heard the maximum numbers of queues or priority groups when a port is shut down, it will mark the port as `pending apply zero profiles` and retry later.
The flow of handling maximum numbers is:
@@ -931,7 +931,7 @@ Let's take queues as an example to explain the principle. Suppose the queues to
In the above example, and `BUFFER_QUEUE_TABLE:Ethernet0:5-7` will be removed from `APPL_DB`, and items `BUFFER_QUEUE_TABLE:Ethernet0:5`, `BUFFER_QUEUE_TABLE:Ethernet0:6` and `BUFFER_QUEUE_TABLE:Ethernet0:7` will be reapplied to `APPL_DB`.
-Even from ASIC's perspective of view, there is no difference before step 5 and after it, this step must be done because if the system undergoes a warm reboot without step 5 done, it doesn't understand what items have been applied to `APPL_DB` and can introduce various items convering the same queues. In the above example, if there is no step 5, after warm reboot the buffer manager will apply `BUFFER_QUEUE_TABLE:Ethernet0:5`, `BUFFER_QUEUE_TABLE:Ethernet0:6` and `BUFFER_QUEUE_TABLE:Ethernet0:7` to `APPL_DB` with zero profiles. However, the item `BUFFER_QUEUE_TABLE:Ethernet0:5-7`, which was applied before warm reboot, is still there.
+Even from ASIC's perspective of view, there is no difference before step 5 and after it, this step must be done because if the system undergoes a warm reboot without step 5 done, it doesn't understand what items have been applied to `APPL_DB` and can introduce various items converting the same queues. In the above example, if there is no step 5, after warm reboot the buffer manager will apply `BUFFER_QUEUE_TABLE:Ethernet0:5`, `BUFFER_QUEUE_TABLE:Ethernet0:6` and `BUFFER_QUEUE_TABLE:Ethernet0:7` to `APPL_DB` with zero profiles. However, the item `BUFFER_QUEUE_TABLE:Ethernet0:5-7`, which was applied before warm reboot, is still there.
In all other scenarios, saving new priority group or queue suffices.
diff --git a/doc/qos/tunnel_dscp_remapping.md b/doc/qos/tunnel_dscp_remapping.md
index 1879280b041..70a171eb8e4 100644
--- a/doc/qos/tunnel_dscp_remapping.md
+++ b/doc/qos/tunnel_dscp_remapping.md
@@ -140,7 +140,7 @@ Before remapping to queue 2 and 6, both queues are required to be cleared. Hence
}
```
- TC_TO_PRIORITY_GROUP_MAP for mappping TC to PG
+ TC_TO_PRIORITY_GROUP_MAP for mapping TC to PG
```json
"TC_TO_PRIORITY_GROUP_MAP": {
diff --git a/doc/rates-and-utilization/Rates_and_utilization_HLD.md b/doc/rates-and-utilization/Rates_and_utilization_HLD.md
index fe4381efb63..03e4618c105 100644
--- a/doc/rates-and-utilization/Rates_and_utilization_HLD.md
+++ b/doc/rates-and-utilization/Rates_and_utilization_HLD.md
@@ -74,7 +74,7 @@ counterpoll [port_rates|rif_rates] interval
counterpoll [port_rates|rif_rates] [enable|disable]
```
-To configure the smoothing interval of moving average new CLI will be intrduced:
+To configure the smoothing interval of moving average new CLI will be introduced:
```
config rate smoothing_interval [all|port|rif]
@@ -134,7 +134,7 @@ For RIF:
### 2.2.4 Exponential moving average
-To make the rates and utilization values more smooth, exponential moving average will be calculated. EMA approximates moving average on a window siza that can be changed dynmically. More recent values are given more weight(imapct the average more, decreasing lag). EMA allows to calculate moving average without storing a set of values. Actually all the values in the series are impacting the EMA, but the weight of older values is infinitely decreasing.
+To make the rates and utilization values more smooth, exponential moving average will be calculated. EMA approximates moving average on a window siza that can be changed dynamically. More recent values are given more weight(impact the average more, decreasing lag). EMA allows to calculate moving average without storing a set of values. Actually all the values in the series are impacting the EMA, but the weight of older values is infinitely decreasing.
ALPHA (precalculated):
@@ -226,10 +226,10 @@ The Lua plugin logic is simple:
### 3.1.5 CLI Scripts
The `counterpoll` utility should return an error when user tries to enable rates when the corresponding counter polling is disabled.
-The `counterpoll` utility should returnwarn the user who is trying to configure rates intervall less than the corresponding counter polling interval,
+The `counterpoll` utility should returnwarn the user who is trying to configure rates interval less than the corresponding counter polling interval,
and configure the same interval as the counters interval.
-The `portstat` and `intfstat` scripst will be updated to display the rates and utilization values from the DB.
+The `portstat` and `intfstat` scripts will be updated to display the rates and utilization values from the DB.
The show CLI commands support a `-p, --period` option, to display values calculated over a specified period of time. For this the approach of taking a snapshot of counters is more suitable. The script should use this approach when `-p` option is used.
### 3.2 Testing
diff --git a/doc/reboot/Reboot_BlockingMode_HLD.md b/doc/reboot/Reboot_BlockingMode_HLD.md
index 955a5954f63..9c15dc2eeb3 100644
--- a/doc/reboot/Reboot_BlockingMode_HLD.md
+++ b/doc/reboot/Reboot_BlockingMode_HLD.md
@@ -102,7 +102,7 @@ The config file path is `/etc/sonic/reboot.conf`. Supported configs as following
|-|-|-|-|
| blocking_mode | true/false | false | Enable Blocking Mode for reboot command |
| blocking_mode_timeout | int (seconds) | 180 | The timeout for enable Blocking Mode. |
-| show_timer | true/false | false | Must enable `blocking_mode` first.Enable Runing Output for blocking mode. |
+| show_timer | true/false | false | Must enable `blocking_mode` first.Enable Running Output for blocking mode. |
Example for `reboot.conf` content:
diff --git a/doc/recirculation-port/recirculation_port.md b/doc/recirculation-port/recirculation_port.md
index a050b1e6dcf..fb233072b6e 100644
--- a/doc/recirculation-port/recirculation_port.md
+++ b/doc/recirculation-port/recirculation_port.md
@@ -54,7 +54,7 @@ To ensure the recycled packet is bridged/routed correctly, the corresponding FDB
In general, recycle-to-routed is more preferred to reccyle-to-bridged because the former can take the advantages of L3 forwarding features like ECMP. However, recycle-to-routed is also having its own limitation/issue. For example, the TTL of the egress packet may be decremented twice because the packet is routed twice.
-## 1.2 Explict recycle ports
+## 1.2 Explicit recycle ports
Since the traffic is forwarded via recycle ports, it’s ideal to have statistics, like counters or errors, collected for recycle ports as well just like for front panel ports. This makes it easier to debug forwarding issue in which recycle ports are involved. To this end recycle ports need to be made visible to SONiC.
@@ -77,7 +77,7 @@ Ethernet24 72,73,74,75,76,77,78,79 Ethernet4/1 4 Ext 400
Ethernet-Rec0 221 Recirc0/0 5 Rec 400000
Ethernet-IB0 222 Recirc0/1 6 Inb 400000
```
-Similarly, if recirculation ports are configued in platform.json, their port role must be provided too. For example, the above recirculation ports are defined in platform.json as shown below:
+Similarly, if recirculation ports are configured in platform.json, their port role must be provided too. For example, the above recirculation ports are defined in platform.json as shown below:
```
"Ethernet-Rec0": {
"index": "5",
diff --git a/doc/release-notes/SONiC_201911_Release_Notes.md b/doc/release-notes/SONiC_201911_Release_Notes.md
index 0c1231f59f9..6de81c214a8 100644
--- a/doc/release-notes/SONiC_201911_Release_Notes.md
+++ b/doc/release-notes/SONiC_201911_Release_Notes.md
@@ -41,7 +41,7 @@ Image : https://sonic-jenkins.westus2.cloudapp.azure.com/ (Example - Image for
# Security Updates
-1. Kernal upgraded from 4.9.110-3deb9u6 (SONiC Release 201904) to 4.9.168-1+deb9u5 in this SONiC release.
+1. Kernel upgraded from 4.9.110-3deb9u6 (SONiC Release 201904) to 4.9.168-1+deb9u5 in this SONiC release.
Change log: https://tracker.debian.org/media/packages/l/linux/changelog-4.9.168-1deb9u5
2. Docker upgraded from 18.09.2\~3-0\~debian-stretch to 18.09.8\~3-0\~debian-stretch.
Change log: https://docs.docker.com/engine/release-notes/#18098
diff --git a/doc/release-notes/SONiC_202012_Release_Notes.md b/doc/release-notes/SONiC_202012_Release_Notes.md
index 125a8f22945..50139457125 100644
--- a/doc/release-notes/SONiC_202012_Release_Notes.md
+++ b/doc/release-notes/SONiC_202012_Release_Notes.md
@@ -102,7 +102,7 @@ This feature is a design change that allows the PHY drivers to be separated from
**Pull Requests** : [347](https://github.com/sonic-net/sonic-swss-common/pull/347), [931](https://github.com/sonic-net/sonic-utilities/pull/931), [1321](https://github.com/sonic-net/sonic-swss/pull/1321), [624](https://github.com/sonic-net/sonic-sairedis/pull/624) & [4851](https://github.com/sonic-net/sonic-buildimage/pull/4851).
#### Kubernetes (docker to be controlled by Kubernetes)
-This feature deals in depth with kubernetes-support. With this feature, an image could be downloaded from external repositaries and kubernetes does the deployment. The external Kubernetes masters could be used to deploy container image updates at a massive scale, through manifests. This new mode is referred as "kubernetes mode".
+This feature deals in depth with kubernetes-support. With this feature, an image could be downloaded from external repositories and kubernetes does the deployment. The external Kubernetes masters could be used to deploy container image updates at a massive scale, through manifests. This new mode is referred as "kubernetes mode".
What we implement in this release:
- The image could be built with kubernetes support
diff --git a/doc/release-notes/SONiC_202106_Release_Notes.md b/doc/release-notes/SONiC_202106_Release_Notes.md
index f3bb3f59901..4b3ff176167 100644
--- a/doc/release-notes/SONiC_202106_Release_Notes.md
+++ b/doc/release-notes/SONiC_202106_Release_Notes.md
@@ -88,7 +88,7 @@ Currently SONiC Testbed setup uses fanout switches to connect to the testbed ser
#### 6. Error handling (swss)
-This feature impliments the orchagent in handling SAI failures. below are the failure handling functions in orchagent
+This feature implements the orchagent in handling SAI failures. below are the failure handling functions in orchagent
* Allow different handling for Create/Set/Remove/Get operations.
* Allow each Orch to have its specific handling logic.
@@ -123,10 +123,10 @@ This feature is an enhancements of SONiC ICCP MCLAG. This includes MCLAG configu
**Pull Requests** : [596](https://github.com/sonic-net/SONiC/pull/596), [885](https://github.com/sonic-net/sonic-swss/pull/885), [4819](https://github.com/sonic-net/sonic-buildimage/pull/4819), [1331](https://github.com/sonic-net/sonic-swss/pull/1331), [1349](https://github.com/sonic-net/sonic-swss/pull/1349), [529](https://github.com/sonic-net/sonic-utilities/pull/529), [405](https://github.com/sonic-net/sonic-swss-common/pull/405), [59](https://github.com/sonic-net/sonic-mgmt-framework/pull/59), [25](https://github.com/sonic-net/sonic-mgmt-common/pull/25)
#### 11. DHCP relay IPv6 support
-This DHCP Relay for IPv6 feature in SONiC impliments the following functionalities,
+This DHCP Relay for IPv6 feature in SONiC implements the following functionalities,
* To give the support for relaying DHCP packets from downstream networks to upstream networks using IPv6 addresses.
-* To provide the functionality as a seperate process running on dhcp-relay docker container.
+* To provide the functionality as a separate process running on dhcp-relay docker container.
* To relay messages to multiple unicast and multicast addresses.
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/DHCPv6_Relay/DHCPv6_Relay_HLD.md) and below mentioned PR's for more details.
diff --git a/doc/release-notes/SONiC_202111_Release_Notes.md b/doc/release-notes/SONiC_202111_Release_Notes.md
index a8b99da2b67..ed5c965a6b6 100644
--- a/doc/release-notes/SONiC_202111_Release_Notes.md
+++ b/doc/release-notes/SONiC_202111_Release_Notes.md
@@ -141,7 +141,7 @@ Refer [HLD document](https://github.com/sonic-net/SONiC/blob/434a5fcc8a5c7f0fe13
**Pull Requests** : [858](https://github.com/sonic-net/SONiC/pull/858), [8940](https://github.com/sonic-net/sonic-buildimage/pull/8940), [1951](https://github.com/sonic-net/sonic-swss/pull/1951), [4456](https://github.com/sonic-net/sonic-mgmt/pull/4456), [1868](https://github.com/sonic-net/sonic-utilities/pull/1868), [954](https://github.com/sonic-net/sonic-sairedis/pull/954), [534](https://github.com/sonic-net/sonic-swss-common/pull/534), [1876](https://github.com/sonic-net/sonic-utilities/pull/1876) & [9353](https://github.com/sonic-net/sonic-buildimage/pull/9353)
#### L2 functional and performance enhancements
-This implentation provides enhancements in SONiC layer 2 forwarding for FDB flush, MAC move, FDB aging time configuration, Static FDB configuration and VLAN Range configuration.
+This implementation provides enhancements in SONiC layer 2 forwarding for FDB flush, MAC move, FDB aging time configuration, Static FDB configuration and VLAN Range configuration.
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/layer2-forwarding-enhancements/SONiC%20Layer%202%20Forwarding%20Enhancements%20HLD.md) and below mentioned PR's for more details.
**Pull Requests** : [379](https://github.com/sonic-net/SONiC/pull/379), [510](https://github.com/sonic-net/sonic-sairedis/pull/510), [303](https://github.com/sonic-net/sonic-swss-common/pull/303), [529](https://github.com/sonic-net/sonic-utilities/pull/529) & [1716](https://github.com/sonic-net/sonic-swss/pull/1716)
@@ -200,13 +200,13 @@ Refer [HLD document](https://github.com/ghooo/SONiC/blob/c1f3f3b5427d0cafb3defd9
**Pull Requests** : [736](https://github.com/sonic-net/SONiC/pull/736), [1536](https://github.com/sonic-net/sonic-utilities/pull/1536), [1599](https://github.com/sonic-net/sonic-utilities/pull/1599), [1762](https://github.com/sonic-net/sonic-utilities/pull/1762), [1794](https://github.com/sonic-net/sonic-utilities/pull/1794), [1831](https://github.com/sonic-net/sonic-utilities/pull/1831), [1856](https://github.com/sonic-net/sonic-utilities/pull/1856), [1864](https://github.com/sonic-net/sonic-utilities/pull/1864), [1885](https://github.com/sonic-net/sonic-utilities/pull/1885), [1901](https://github.com/sonic-net/sonic-utilities/pull/1901), [1919](https://github.com/sonic-net/sonic-utilities/pull/1919), [1923](https://github.com/sonic-net/sonic-utilities/pull/1923), [1929](https://github.com/sonic-net/sonic-utilities/pull/1929), [1934](https://github.com/sonic-net/sonic-utilities/pull/1934), [1969](https://github.com/sonic-net/sonic-utilities/pull/1969), [1973](https://github.com/sonic-net/sonic-utilities/pull/1973), [1977](https://github.com/sonic-net/sonic-utilities/pull/1977), [1981](https://github.com/sonic-net/sonic-utilities/pll/1981), [1983](https://github.com/sonic-net/sonic-utilities/pull/1983), [1987](https://github.com/sonic-net/sonic-utilities/pull/1987), [1988](https://github.com/sonic-net/sonic-utilities/pull/1988), [2003](https://github.com/sonic-net/sonic-utilities/pull/2003), [2006](https://github.com/sonic-net/sonic-utilities/pull/2006), [2008](https://github.com/sonic-net/sonic-utilities/pull/2008), [2015](https://github.com/sonic-net/sonic-utilities/pull/2015), [2020](https://github.com/sonic-net/sonic-utilities/pull/2020) & [2028](https://github.com/sonic-net/sonic-utilities/pull/2028)
#### SRv6 support (Cntd)
-SRv6 has been widely adopted as an IPv6 based SDN solution, which provides programming ability, TE capabilities, and deployment simplicity to network administrators. With current support from a rich ecosystem, including major ASIC manufactures, networking vendors and open source communities, the deployment of SRv6 is accelerating. This implentation adds SRv6 into SONIC to benefit users in DC as well as beyond DC.
+SRv6 has been widely adopted as an IPv6 based SDN solution, which provides programming ability, TE capabilities, and deployment simplicity to network administrators. With current support from a rich ecosystem, including major ASIC manufactures, networking vendors and open source communities, the deployment of SRv6 is accelerating. This implementation adds SRv6 into SONIC to benefit users in DC as well as beyond DC.
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/faa432df6185f7c04d896285db61ac86300161c9/doc/srv6/srv6-hld-v19.md) and below mentioned PR's for more details.
**Pull Requests** : [795](https://github.com/sonic-net/SONiC/pull/795), [9238](https://github.com/sonic-net/sonic-buildimage/pull/9238), [538](https://github.com/sonic-net/sonic-swss-common/pull/538), [1964](https://github.com/sonic-net/sonic-swss/pull/1964) & [1883](https://github.com/sonic-net/sonic-utilities/pull/1883)
#### Upgrade SONiC init flow
-This implentation is to introduce a new API for query statistics capabilities of counters in a faster and more efficient way. Currently on SONiC, in order to get the counters capabilities, SONiC is iterating all port stats one by one, to understand the supported capabilities. This operation is time consuming and the new API can reduce the time for this operation in one call.
+This implementation is to introduce a new API for query statistics capabilities of counters in a faster and more efficient way. Currently on SONiC, in order to get the counters capabilities, SONiC is iterating all port stats one by one, to understand the supported capabilities. This operation is time consuming and the new API can reduce the time for this operation in one call.
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/Query_Stats_Capability/Query_Stats_Capability_HLD.md) and below mentioned PR's for more details.
**Pull Requests** : [871](https://github.com/sonic-net/SONiC/pull/871) & [952](https://github.com/sonic-net/sonic-sairedis/pull/952)
diff --git a/doc/release-notes/SONiC_202205_Release_Notes.md b/doc/release-notes/SONiC_202205_Release_Notes.md
index 5e173089954..3ff23e154f2 100644
--- a/doc/release-notes/SONiC_202205_Release_Notes.md
+++ b/doc/release-notes/SONiC_202205_Release_Notes.md
@@ -62,7 +62,7 @@ Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/dualtor/
#### Add SAI version check to SONiC build system
-SONiC is not desinged to work in backward compatibility with older vendor SAI implementations. SAI headers that SONiC's synd daemon is compiled against are taken from OCP SAI repository. So is taken from sonic-buildimage vendor's directory. This leads to a conflict that sometimes SAI in sonic-sairedis repository is updated but vendor SAI in sonic-buildimage is not. This implementation sorts out this conflicts.
+SONiC is not designed to work in backward compatibility with older vendor SAI implementations. SAI headers that SONiC's synd daemon is compiled against are taken from OCP SAI repository. So is taken from sonic-buildimage vendor's directory. This leads to a conflict that sometimes SAI in sonic-sairedis repository is updated but vendor SAI in sonic-buildimage is not. This implementation sorts out this conflicts.
Refer below mentioned PR for more details.
**Pull Requests** : [935](https://github.com/sonic-net/SONiC/pull/935)
@@ -76,7 +76,7 @@ Refer below mentioned PR for more details.
#### Added fan_drawer class support in PDDF
-This enhancement impliments the changes to attach the PSU related thermal sensors in the PSU instance. This is acheieved by adding a common class pddf_fan_drawer.py. This class uses the PDDF JSON to fetch the platform specific data. previously, the fan_drawer support was missing in PDDF common platform APIs. This resulted in 'thermalctld' not working and 'show platform fan' and 'show platfomr temperature' commands not working. As _thermal_list array inside PSU class was not initialized.
+This enhancement implements the changes to attach the PSU related thermal sensors in the PSU instance. This is acheieved by adding a common class pddf_fan_drawer.py. This class uses the PDDF JSON to fetch the platform specific data. previously, the fan_drawer support was missing in PDDF common platform APIs. This resulted in 'thermalctld' not working and 'show platform fan' and 'show platform temperature' commands not working. As _thermal_list array inside PSU class was not initialized.
Refer below mentioned PR for more details.
**Pull Requests** : [10213](https://github.com/sonic-net/sonic-buildimage/pull/10213)
@@ -112,7 +112,7 @@ Refer below mentioned PR's for more details.
#### Deterministic interface Link bring-up
-This feature impliments the determistic approach for Interface link bring-up sequence for all interfaces types i.e. below sequence to be followed:
+This feature implements the deterministic approach for Interface link bring-up sequence for all interfaces types i.e. below sequence to be followed:
- Initialize and enable NPU Tx and Rx path
- For system with 'External' PHY: Initialize and enable PHY Tx and Rx on both line and host sides; ensure host side link is up
@@ -137,7 +137,7 @@ Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/pbh/pbh-
#### Extend auto tech support for memory threshold
-Currently, techsupport is run by invoking show techsupport either by orchestration tools or manually. The techsupport dump also collects any core dump files available in the /var/core/ directory. However upon the techsupport invocation be made event-driven based on core dump generation, that would improve the debuggability which is implimented on this enhancement.
+Currently, techsupport is run by invoking show techsupport either by orchestration tools or manually. The techsupport dump also collects any core dump files available in the /var/core/ directory. However upon the techsupport invocation be made event-driven based on core dump generation, that would improve the debuggability which is implemented on this enhancement.
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/auto_techsupport_and_coredump_mgmt.md) and below mentioned PR's for more details.
**Pull Requests** : [939](https://github.com/sonic-net/SONiC/pull/939), [2116](https://github.com/sonic-net/sonic-utilities/pull/2116) & [10433](https://github.com/sonic-net/sonic-buildimage/pull/10433)
@@ -206,7 +206,7 @@ The docker images to debian bullseye for this release are listed below.
```
#### Move Nvidia syncd and pmon to Debian11- "Bullseye"
-This impliments the upgrade on nvidia platform for containers such as syncd / saiserver / syncd-rpc and pmon to bullseye
+This implements the upgrade on nvidia platform for containers such as syncd / saiserver / syncd-rpc and pmon to bullseye
Refer below mentioned PR's for more details.
**Pull Requests** : [10580](https://github.com/sonic-net/sonic-buildimage/pull/10580)
@@ -241,7 +241,7 @@ Refer [HLD document](https://github.com/sonic-net/SONiC/blob/5a5922499b388acafa8
#### Platform support for Edgecore AS4630/AS7326/AS7816/AS5835
-This feature impliments the sonic-buildimage changes needed to support in platform for AS4630-pe, AS5835-X, AS7326, AS7816 switch models (currently broken in master).
+This feature implements the sonic-buildimage changes needed to support in platform for AS4630-pe, AS5835-X, AS7326, AS7816 switch models (currently broken in master).
Refer below mentioned PR's for more details.
**Pull Requests** : [10053](https://github.com/Azure/sonic-buildimage/pull/10053)
@@ -287,9 +287,9 @@ Refer below mentioned PR's for more details.
#### Sorted next hop ECMP
-Under the ToR (Tier0 device) there can be appliances (eg:Firewall/Software-Load Balancer) which maintain state of flows running through them. For better scaling/high-availaibility/fault-tolerance set of appliances are used and connected to differnt ToR's. Not all the flow state that are maintained by these appliances in a set are shared between them. Thus with flow state not being sync if the flow do not end up alawys on to same TOR/Appliance it can cause services (using that flow) degradation and also impact it's availability
+Under the ToR (Tier0 device) there can be appliances (eg:Firewall/Software-Load Balancer) which maintain state of flows running through them. For better scaling/high-availaibility/fault-tolerance set of appliances are used and connected to different ToR's. Not all the flow state that are maintained by these appliances in a set are shared between them. Thus with flow state not being sync if the flow do not end up alawys on to same TOR/Appliance it can cause services (using that flow) degradation and also impact it's availability
-To make sure given flow (identidied by 5 tuple) always end up on to same TOR/Appliance we need ECMP ordered support/feature on T1 (Leaf Router). With this feature enable even if flow land's on different T1's (which is common to happen as some link/device in the flow path goes/come to/from maintainence) ECMP memeber being ordered will use same nexthop (T0) and thus same appliace.
+To make sure given flow (identified by 5 tuple) always end up on to same TOR/Appliance we need ECMP ordered support/feature on T1 (Leaf Router). With this feature enable even if flow land's on different T1's (which is common to happen as some link/device in the flow path goes/come to/from maintenance) ECMP member being ordered will use same nexthop (T0) and thus same appliace.
Refer [HLD document](https://github.com/sonic-net/SONiC/blob/master/doc/bum_storm_control/bum_storm_control_hld.md) and below mentioned PR's for more details.
**Pull Requests** : [896](https://github.com/sonic-net/SONiC/pull/896), [9651](https://github.com/sonic-net/sonic-buildimage/pull/9651), [2092](https://github.com/sonic-net/sonic-swss/pull/2092) & [989](https://github.com/sonic-net/sonic-sairedis/pull/989)
diff --git a/doc/release-notes/SONiC_202211_Release_Notes.md b/doc/release-notes/SONiC_202211_Release_Notes.md
index e8fc965719b..f6994e0367e 100644
--- a/doc/release-notes/SONiC_202211_Release_Notes.md
+++ b/doc/release-notes/SONiC_202211_Release_Notes.md
@@ -57,7 +57,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| **Add syslog message rate limit configuration per container** | This feature allows user to configure SystemLogRateLimitInterval and SystemLogRateLimitBurst for host, containers. There is no rate limiting configured on host side for now. | [1049](https://github.com/sonic-net/SONiC/pull/1049), [22](https://github.com/sonic-net/sonic-host-services/pull/22), [2454](https://github.com/sonic-net/sonic-utilities/pull/2454), [12488](https://github.com/sonic-net/sonic-buildimage/pull/12488), [12490](https://github.com/sonic-net/sonic-buildimage/pull/12490), [12489](https://github.com/sonic-net/sonic-buildimage/pull/12489) &[6627](https://github.com/sonic-net/sonic-mgmt/pull/6627) |
| **Auto Neg Enhancement** | This feature does not change the existing SONiC architecture. This feature introduces a few new CLI commands which will fit in sonic-utilities. And this feature also requires to change the configuration flow for port auto negotiation attributes which will be covered in orchagent. | [924](https://github.com/sonic-net/SONiC/pull/924), [1038](https://github.com/sonic-net/sonic-sairedis/pull/1038), [2359](https://github.com/sonic-net/sonic-swss/pull/2359), [614](https://github.com/sonic-net/sonic-swss-common/pull/614) & [2124](https://github.com/sonic-net/sonic-utilities/pull/2124) |
| **BRCM KNET sflow psample API compliance upgrade** | This feature is an enhancement on BRCM KNET modules to support new psample definitions from sflow dropmon feature | [11709](https://github.com/sonic-net/sonic-buildimage/pull/11709) & [10](https://github.com/sonic-net/saibcm-modules/pull/10) |
-| **Build Time Improvement - Version cache framework** | This feature gives the Functionality and High level design of the build improvement in SONiC. This feature provides improvements in three essential areas. Multi user build
- Parallel build using Native docker mode.
- OverlayFS to virtualize the build root.
Build time Optimization
- Parallel make jobs - Passing dh '-parallel' flags to all the build targets.
- Binary image build optimization
- Use tmpfs and OverlayFS to speed up the build process.
Build caching
- Version cache - Package cache support for build componets that are downloaded from external world.
- Image cache support for installer image componets.
| [942](https://github.com/sonic-net/SONiC/pull/942), [10352](https://github.com/sonic-net/sonic-buildimage/pull/10352), [12000](https://github.com/sonic-net/sonic-buildimage/pull/12000), [12001](https://github.com/sonic-net/sonic-buildimage/pull/12001) & [12005](https://github.com/sonic-net/sonic-buildimage/pull/12005) |
+| **Build Time Improvement - Version cache framework** | This feature gives the Functionality and High level design of the build improvement in SONiC. This feature provides improvements in three essential areas. Multi user build
- Parallel build using Native docker mode.
- OverlayFS to virtualize the build root.
Build time Optimization
- Parallel make jobs - Passing dh '-parallel' flags to all the build targets.
- Binary image build optimization
- Use tmpfs and OverlayFS to speed up the build process.
Build caching
- Version cache - Package cache support for build components that are downloaded from external world.
- Image cache support for installer image components.
| [942](https://github.com/sonic-net/SONiC/pull/942), [10352](https://github.com/sonic-net/sonic-buildimage/pull/10352), [12000](https://github.com/sonic-net/sonic-buildimage/pull/12000), [12001](https://github.com/sonic-net/sonic-buildimage/pull/12001) & [12005](https://github.com/sonic-net/sonic-buildimage/pull/12005) |
| **Bullseye Docker Migration - FRR, PDE, BRCM Platform, ICCPD** | This implements the migration from buster to bullseye. | [10864](https://github.com/sonic-net/sonic-buildimage/pull/10864), [10836](https://github.com/sonic-net/sonic-buildimage/pull/10836), [30](https://github.com/sonic-net/sonic-platform-pdk-pde/pull/30), [11777](https://github.com/sonic-net/sonic-buildimage/pull/11777) & [12097](https://github.com/sonic-net/sonic-buildimage/pull/12097) |
| **Bulk counters** | This feature implements the design specification for bulk counter feature on SONiC. SONiC flex counter infrastructure shall utilize bulk stats API to gain better performance. This feature discusses how to integrate these two new APIs to SONiC. | [1009](https://github.com/sonic-net/SONiC/pull/1009) & [1094](https://github.com/sonic-net/sonic-sairedis/pull/1094) |
| **General config CLI validation by YANG model** | Currently, SONiC config fields updates are validated ad-hoc, and much of the validation criteria are duplicated both in python (hard-coded validation specs) and in YANG models. In this release, the Refactor code is to utilize preexisting YANG models for config validation, instead of duplicating the validation specs in both YANG and in python.| [1072](https://github.com/sonic-net/SONiC/pull/1072), [2147](https://github.com/sonic-net/sonic-utilities/pull/2147), [12497](https://github.com/sonic-net/sonic-buildimage/pull/12497), [12504](https://github.com/sonic-net/sonic-buildimage/pull/12504), [2190](https://github.com/sonic-net/sonic-utilities/pull/2190), [2420](https://github.com/sonic-net/sonic-utilities/pull/2420), [2430](https://github.com/sonic-net/sonic-utilities/pull/2430), [2452](https://github.com/sonic-net/sonic-utilities/pull/2452), [2481](https://github.com/sonic-net/sonic-utilities/pull/2481), [2498](https://github.com/sonic-net/sonic-utilities/pull/2498), [2526](https://github.com/sonic-net/sonic-utilities/pull/2526), [2604](https://github.com/sonic-net/sonic-utilities/pull/2604) & [2755](https://github.com/sonic-net/sonic-utilities/pull/2755) |
diff --git a/doc/release-notes/SONiC_202305_Release_Notes.md b/doc/release-notes/SONiC_202305_Release_Notes.md
index 4b8419da924..ecad2acd61a 100644
--- a/doc/release-notes/SONiC_202305_Release_Notes.md
+++ b/doc/release-notes/SONiC_202305_Release_Notes.md
@@ -55,14 +55,14 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| Feature| Feature Description | HLD PR / PR tracking | Quality |
| ------ | ------- | -----|-----|
| ***ACL keys for matching BTH_opcode and AETH_syndrome*** | This feature deals with ACL key BTH_OPCODE and AETH_SYNDROME | [1247](https://github.com/sonic-net/SONiC/issues/1247), [13340](https://github.com/sonic-net/sonic-buildimage/pull/13340) & [2617](https://github.com/sonic-net/sonic-swss/pull/2617) | NA* |
-| ***Auto tech support w/orchagent abort case*** | It is highly likely that by the time auto-techsupport collects saisdkdump, syncd might have been restarted or in the process of restarting. In either case, we'd be loosing the saisdkdump information before restart which will contain useful information for triaging. Thus, a special handling is needed for the core dumps generated from swss container which is handled in this feature enhancement. | [1175](https://github.com/sonic-net/SONiC/issues/1175) , [1212](https://github.com/sonic-net/SONiC/pull/1212), [2644](https://github.com/sonic-net/sonic-swss/pull/2644), [1198](https://github.com/sonic-net/sonic-sairedis/pull/1198), [2633](https://github.com/sonic-net/sonic-utilities/pull/2633) & [13533](https://github.com/sonic-net/sonic-buildimage/pull/13533) | NA* |
+| ***Auto tech support w/orchagent abort case*** | It is highly likely that by the time auto-techsupport collects saisdkdump, syncd might have been restarted or in the process of restarting. In either case, we'd be losing the saisdkdump information before restart which will contain useful information for triaging. Thus, a special handling is needed for the core dumps generated from swss container which is handled in this feature enhancement. | [1175](https://github.com/sonic-net/SONiC/issues/1175) , [1212](https://github.com/sonic-net/SONiC/pull/1212), [2644](https://github.com/sonic-net/sonic-swss/pull/2644), [1198](https://github.com/sonic-net/sonic-sairedis/pull/1198), [2633](https://github.com/sonic-net/sonic-utilities/pull/2633) & [13533](https://github.com/sonic-net/sonic-buildimage/pull/13533) | NA* |
| ***Build Time Improvement Version Caching Support*** | This features enhances the build time improvement phase 2 - version caching support for python and wget | [1177](https://github.com/sonic-net/SONiC/issues/1177), [942](https://github.com/sonic-net/SONiC/pull/942), [10352](https://github.com/sonic-net/sonic-buildimage/pull/10352), [12000](https://github.com/sonic-net/sonic-buildimage/pull/12000), [12001](https://github.com/sonic-net/sonic-uildimage/pull/12001), [12005](https://github.com/sonic-net/sonic-buildimage/pull/12005), [14612](https://github.com/sonic-et/sonic-buildimage/pull/14612) & [14613](https://github.com/sonic-net/sonic-buildimage/pull/14613) | NA* |
| ***Chassis - execute Line card cmds from Sup remotely*** | This feature not a HLD PR but issue for release tracking purpose. | [2701](https://github.com/sonic-net/sonic-utilities/pull/2701) | NA* |
| ***Collecting dump during SAI failure*** | This feature is to describe the flow to collect useful dumps during SAI failures. | [1212](https://github.com/sonic-net/SONiC/pull/1212), [2644](https://github.com/sonic-net/sonic-swss/pull/2644), [1198](https://github.com/sonic-net/sonic-sairedis/pull/1198), [2633](https://github.com/sonic-net/sonic-utilities/pull/2633) & [13533](https://github.com/sonic-net/sonic-buildimage/pull/13533) | NA* |
| ***Config Reload Enhancement*** | This feature enhances config reload to sequence the services and faster system initialization. | [1203](https://github.com/sonic-net/SONiC/pull/1203), [45](https://github.com/sonic-net/sonic-host-services/pull/45), [2693](https://github.com/sonic-net/sonic-utilities/pull/2693), [13969](https://github.com/sonic-net/sonic-buildimage/pull/13969) & [7558](https://github.com/sonic-net/sonic-mgmt/pull/7558) | NA* |
| ***Docker migration to Bullseye*** | Docker migration to Bullseye | [1242](https://github.com/sonic-net/SONiC/issues/1242) | NA* |
| ***FIB Suppress Announcements of Routes Not Installed in HW*** | This feature describes a feedback mechanism that allows BGP not to advertise routes that haven't been programmed yet. | [1103](https://github.com/sonic-net/SONiC/pull/1103), [2492](https://github.com/sonic-net/sonic-swss/pull/2492), [708](https://github.com/sonic-net/sonic-swss-common/pull/708), [2511](https://github.com/sonic-net/sonic-swss/pull/2511), [2512](https://github.com/sonic-net/sonic-swss/pull/2512), [2495](https://github.com/sonic-net/sonic-utilities/pull/2495), [12852](https://github.com/sonic-net/sonic-buildimage/pull/12852), [12853](https://github.com/sonic-net/sonic-buildimage/pull/12853), [2551](https://github.com/sonic-net/sonic-swss/pull/2551), [2531](https://github.com/sonic-net/sonic-utilities/pull/2531), [7475](https://github.com/sonic-net/sonic-mgmt/pull/7475) & [7430](https://github.com/sonic-net/sonic-mgmt/pull/7430) | NA* |
-| ***MDIO IPC Client Library*** | This feature is an extention based on earlier HLD merged last year for add MDIO IPC Client library support. | [1230](https://github.com/sonic-net/sonic-sairedis/pull/1230) | NA* |
+| ***MDIO IPC Client Library*** | This feature is an extension based on earlier HLD merged last year for add MDIO IPC Client library support. | [1230](https://github.com/sonic-net/sonic-sairedis/pull/1230) | NA* |
| ***PDDF FPGA Device Support*** | This feature is to enhance PDDF framework to support PCIe based FPGA devices and I2C based FPGA devices. | [1232](https://github.com/sonic-net/SONiC/pull/1232), [13475](https://github.com/sonic-net/sonic-buildimage/pull/13475), [13476](https://github.com/sonic-net/sonic-buildimage/pull/13476), [13477](https://github.com/sonic-net/sonic-buildimage/pull/13477) & [13474](https://github.com/sonic-net/sonic-buildimage/pull/13474) | NA* |
| ***PDDF S3IP Compliant SysFS Path Support*** | This feature is to enhance PDDF framework to generate or map SysFS as per S3IP spec | [1294](https://github.com/sonic-net/SONiC/pull/1294), [15073](https://github.com/sonic-net/sonic-buildimage/pull/15073), [15074](https://github.com/sonic-net/sonic-buildimage/pull/15074) & [15075](https://github.com/sonic-net/sonic-buildimage/pull/15075) | NA* |
| ***PINS Generic SAI Extensions resource monitoring support*** | Critical resource monitoring for dyNA*mic PINS Generic SAI Extensions objects. | [1205](https://github.com/sonic-net/SONiC/issues/1205), [1243](https://github.com/sonic-net/SONiC/pull/1243) & [2649](https://github.com/sonic-net/sonic-swss/pull/2649) | NA* |
diff --git a/doc/release-notes/SONiC_202311_Release_Notes.md b/doc/release-notes/SONiC_202311_Release_Notes.md
index c54a2fb8173..2e98817fa5c 100644
--- a/doc/release-notes/SONiC_202311_Release_Notes.md
+++ b/doc/release-notes/SONiC_202311_Release_Notes.md
@@ -86,7 +86,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| ***Virtual SONiC Network Helper*** | This feature implements vsnet tool to create network of virtual sonic instances | [8459](https://github.com/sonic-net/sonic-mgmt/pull/8459) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
-Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" coloumn. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" coloumn along with HLD PRs.
+Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" column. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" column along with HLD PRs.
# SAI APIs
diff --git a/doc/release-notes/SONiC_202405_Release_Notes.md b/doc/release-notes/SONiC_202405_Release_Notes.md
index 2b0bfbc7c3c..2c916a7c1dc 100644
--- a/doc/release-notes/SONiC_202405_Release_Notes.md
+++ b/doc/release-notes/SONiC_202405_Release_Notes.md
@@ -55,7 +55,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| Feature| Feature Description | HLD PR / PR tracking | Quality |
| ------ | ------- | -----|-----|
| ***[LLDP][T2] Advertise Chassis Hostname when present.*** | This feature is for chassis to advertise chassis hostname instead of line card hostname if available to LLDP peers. | [19076](https://github.com/sonic-net/sonic-buildimage/pull/19076) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
-| ***[NTP] Fix config template to init default parameters*** | This implements the fix for NTP config generation from the minigraph and save backward compatability | [18736](https://github.com/sonic-net/sonic-buildimage/pull/18736) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
+| ***[NTP] Fix config template to init default parameters*** | This implements the fix for NTP config generation from the minigraph and save backward compatibility | [18736](https://github.com/sonic-net/sonic-buildimage/pull/18736) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***[SubnetDecap] Add subnet decap HLD*** | This feature implements the subnet decapsulation feature on T0 SONiC that allows Netscan to probe VLAN subnet IP addresses. | [1657](https://github.com/sonic-net/SONiC/pull/1657) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Add details of sff_mgr regarding deterministic bringup for SFF compliant modules*** | This feature adds a new thread sff_mgr under xcvrd to provide deterministic link bringup feature for SFF compliant modules (100G/40G) | [1334](https://github.com/sonic-net/SONiC/pull/1334) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Add HLD for IPv4 port based DHCP server in SONiC*** | This feature implements the design details of ipv4 port based DHCP server in SONiC. | [1282](https://github.com/sonic-net/SONiC/pull/1282) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
@@ -94,7 +94,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| ***Weighted-Cost Multi-Path*** | This feature provides general information about Weighted-Cost Multi-Path implementation in SONiC | [1629](https://github.com/sonic-net/SONiC/pull/1629) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
-Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" coloumn. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" coloumn along with HLD PRs.
+Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" column. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" column along with HLD PRs.
# SAI APIs
diff --git a/doc/release-notes/SONiC_202411_Release_Notes.md b/doc/release-notes/SONiC_202411_Release_Notes.md
index 834f02cbbf7..b6bae75aae4 100644
--- a/doc/release-notes/SONiC_202411_Release_Notes.md
+++ b/doc/release-notes/SONiC_202411_Release_Notes.md
@@ -60,7 +60,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| ***BBR and Overlay ECMP coexistence with dual ToR*** | This feature adds the logic to give Vnet routes precedence over BGP learnt route. This feature also refactors the test_vnet.py to break out the common code into a library. | [1735](https://github.com/sonic-net/SONiC/issues/1735) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***BMP for monitoring SONiC BGP info*** | This feature is to bring up BMP container on SONiC, which is forked from openbmp project with some code changes, by that we could improve the SONiC debuggability and BGP service monitoring efficiency. | [1621](https://github.com/sonic-net/SONiC/pull/1621) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Broadcom syncd bookworm upgrade*** | This feature implements the migration of platform broadcom docker syncd from bullseye to bookworm | [19712](https://github.com/sonic-net/sonic-buildimage/pull/19712) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
-| ***Everflow DSCP marking using Metadata*** | This feature implements the High level design of a new table type which can change the outer DSCP of a packet encapsulated by ther ASIC pipeline while preserving the orignal packets inner DSCP value. | [1743](https://github.com/sonic-net/SONiC/pull/1743) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
+| ***Everflow DSCP marking using Metadata*** | This feature implements the High level design of a new table type which can change the outer DSCP of a packet encapsulated by there ASIC pipeline while preserving the original packets inner DSCP value. | [1743](https://github.com/sonic-net/SONiC/pull/1743) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***HLD for cli sessions feature*** | This feature describes the requirements, architecture and general flow details of serial connection config in SONIC OS based switches. | [1367](https://github.com/sonic-net/SONiC/pull/1367) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Mac Authentication Bypass*** | This feature implements MAB protocol related common header files for generic files and its changes. | [1854](https://github.com/sonic-net/SONiC/issues/1854) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Port Access Control Phase 1*** | This feature provides a means of preventing unauthorized access by users to the services offered by a Network. | [1315](https://github.com/sonic-net/SONiC/pull/1315) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
@@ -69,7 +69,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| ***Upgrade to FRR 10.0.1*** | This implements the version update for FRR to version 10.0.1 | [1565](https://github.com/sonic-net/SONiC/issues/1565) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
-Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" coloumn. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" coloumn along with HLD PRs.
+Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" column. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" column along with HLD PRs.
# SAI APIs
diff --git a/doc/release-notes/SONiC_202505_Release_Notes.md b/doc/release-notes/SONiC_202505_Release_Notes.md
index e92abb00a9e..428c2ecee5e 100644
--- a/doc/release-notes/SONiC_202505_Release_Notes.md
+++ b/doc/release-notes/SONiC_202505_Release_Notes.md
@@ -55,7 +55,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
| Feature| Feature Description | HLD PR / PR tracking | Quality |
| ------ | ------- | -----|-----|
| ***Add hld for DHCPv4 relay per-interface counter*** | This feature describes the details of DHCPv4 Relay per-interface counter feature. It provides capability to count DHCPv4 packets based on packets type and ingress / egress interface. | [1861](https://github.com/sonic-net/SONiC/pull/1861) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
-| ***Add tunnel pipe mode support for IPIP Decap mode to use SAI_TUNNEL_ATTR_DECAP_QOS_DSCP_TO_TC_MAP*** | Thie feature supports the pipe mode in IPIP packets when decapped - request from NetScan. Current support is for all platforms except broadcom SKUs. SAI attribute SAI_TUNNEL_ATTR_DECAP_QOS_DSCP_TO_TC_MAP will be used since the decap_dscp_to_tc_map key is set in the template. | [21868](https://github.com/sonic-net/sonic-buildimage/pull/21868) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
+| ***Add tunnel pipe mode support for IPIP Decap mode to use SAI_TUNNEL_ATTR_DECAP_QOS_DSCP_TO_TC_MAP*** | This feature supports the pipe mode in IPIP packets when decapped - request from NetScan. Current support is for all platforms except broadcom SKUs. SAI attribute SAI_TUNNEL_ATTR_DECAP_QOS_DSCP_TO_TC_MAP will be used since the decap_dscp_to_tc_map key is set in the template. | [21868](https://github.com/sonic-net/sonic-buildimage/pull/21868) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Add Srv6 static config HLD*** | This feature implements the change in SONiC to support static configuration of Segment-routing over IPv6. Besides, a YANG model specification for the new table in CONFIG_DB is also defined. | [1860](https://github.com/sonic-net/SONiC/pull/1860) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***Authentication Support for 802.1X and MAB*** | This feature supports the authentication for 802.1X and for MAB support | [1977](https://github.com/sonic-net/SONiC/issues/1977) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
| ***CVL Enhancements*** | This feature enhances the cvl custom validation to demonstrate its capability to allow/deny configuration based on other db data. | [1969](https://github.com/sonic-net/SONiC/issues/1969) | [Alpha](https://github.com/sonic-net/SONiC/blob/master/doc/SONiC%20feature%20quality%20definition.md) |
@@ -89,7 +89,7 @@ Note : The kernel version is migrated to the version that is mentioned in the fi
-Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" coloumn. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" coloumn along with HLD PRs.
+Note : The HLD PR's have been updated in ""HLD PR / PR tracking"" column. The code PR's part of the features are mentioned within the HLD PRs. The code PRs not mentioned in HLD PRs are updated in "HLD PR / PR tracking" column along with HLD PRs.
# SAI APIs
diff --git a/doc/rif-counters/RIF_counters.md b/doc/rif-counters/RIF_counters.md
index d756721deb0..7316c650727 100644
--- a/doc/rif-counters/RIF_counters.md
+++ b/doc/rif-counters/RIF_counters.md
@@ -53,7 +53,7 @@ The information should be: RX: OK, ERR in packets and bytes. TX: OK, ERR in pack
The CLI command format and example output
```
-$ show interfaces counters rif [OPTOINS] [interface_name]
+$ show interfaces counters rif [OPTIONS] [interface_name]
Show interface counters
@@ -215,7 +215,7 @@ typedef enum _sai_router_interface_stat_t
We can expose the rif counters via sonic telemetry.
The telemetry is able to access the data in SONiC databases according to the schema,
-but for more simplicity virtual path can be used. Virtual path allows to querry for counters by interface name, instead of VID.
+but for more simplicity virtual path can be used. Virtual path allows to query for counters by interface name, instead of VID.
Example virtual paths
diff --git a/doc/s3ip_sysfs/s3ip_sysfs_hld.md b/doc/s3ip_sysfs/s3ip_sysfs_hld.md
index f1ed6786597..ade06d3864e 100644
--- a/doc/s3ip_sysfs/s3ip_sysfs_hld.md
+++ b/doc/s3ip_sysfs/s3ip_sysfs_hld.md
@@ -64,7 +64,7 @@ The S3IP sysfs specification is represented as an organized sysfs directory stru
Both vendors and users should comply with the S3IP sysfs specification. Device vendors focus on the specification implementation, while users verify the usability of the device against this specification. Vendors should provide software access to every sensor capable of being read. For any available sensor, vendors shall provide S3IP sysfs access.
-Figure2-2 S3IP sysfs diretory demo
+Figure2-2 S3IP sysfs directory demo
@@ -297,7 +297,7 @@ However, there are many differences between the two frameworks, which are listed
|-|-|-|
|Requirements| The requirements are put forward from the user's perspective, and the sysfs node is summarized from the actual operation experience. The goal is to unify the interface for device management | The requirements are proposed from technical point of view aimed at platform driver and APIs development in SONiC. Only those SysFS which are required by SONiC platform APIs are exposed.
|Ecosystem | Devices compliant with S3IP SYSFS specification have been widely used in data centers.
The [S3IP](http://www.s3ip.org/) project involved both vendors and users[S3IP] (including Tencent, Alibaba, Baidu, Kuaishou, Meituan, Jingdong and more than a dozen ODM vendors). Vendors and users complete a closed-loop of requirements, standards and debugging tools that have the ability to iterate continuously. | PDDF is a new framework and it is developed in the SONiC context. Some ODM platforms are already using PDDF. PDDF is an underlying framework which ODMs can use for faster development but it does not exposes any fixed SysFS nodes to the user.
-|Development Mode | Regular development model,
Programming is required to implement the requirements.
ODM venders need to provide professional driver support for customers，Customers validating device with sysfs| ODM vendors can use common PDDF kernel drivers and user space common platform APIs. Only some platform specific device data needs to be provided by the ODMs in the form of JSON files. Validation is via usual SONiC CLIs.
+|Development Mode | Regular development model,
Programming is required to implement the requirements.
ODM vendors need to provide professional driver support for customers，Customers validating device with sysfs| ODM vendors can use common PDDF kernel drivers and user space common platform APIs. Only some platform specific device data needs to be provided by the ODMs in the form of JSON files. Validation is via usual SONiC CLIs.
|Flexible | 1.Bus independent, The hardware support:
Fan
PSU
System EEPROM
Transceivers
CPLD
FPGA
System LED
Temperature sensors
Current sensors
Voltage sensors
Slot
Watchdog
2.Support scenarios with many customization requirements, such as FPGA-Polling, BMC management hardware and firmware upgrades
3.Normalized SYSFS is easy for hardware fault identification and prediction
4.Easy to debug for ODM users, and they need not care about the bus topology |PDDF can be used on the platforms which use I2C bus to communicate with the peripheral devices. Platforms which use BMC can also be brought up using PDDF. In future PDDF would be supported on platform using PCIE FPGA devices.
|code position | https://github.com/sonic-net/sonic-buildimage/tree/master/platform/s3ip-sysfs| https://github.com/sonic-net/sonic-buildimage/tree/master/platform/pddf
diff --git a/doc/s3ip_sysfs/s3ip_sysfs_specification.md b/doc/s3ip_sysfs/s3ip_sysfs_specification.md
index a88ecb497c7..3b3ed252c32 100644
--- a/doc/s3ip_sysfs/s3ip_sysfs_specification.md
+++ b/doc/s3ip_sysfs/s3ip_sysfs_specification.md
@@ -5,7 +5,7 @@
* [2. Temperature sensor sysfs](#2-temperature-sensor-sysfs)
* [3. Voltage sensor sysfs](#3-voltage-sensor-sysfs)
* [4. Current sensor sysfs ](#4-current-sensor-sysfs)
- * [5. Syseeprom infomation sysfs ](#5-syseeprom-information-sysfs)
+ * [5. Syseeprom information sysfs ](#5-syseeprom-information-sysfs)
* [6. Fan information sysfs](#6-fan-information-sysfs)
* [7. PSU information sysfs](#7-psu-information-sysfs)
* [8. Transceiver information sysfs](#8-transceiver-information-sysfs)
diff --git a/doc/sag/sag-HLD.md b/doc/sag/sag-HLD.md
index 02d2ec670f8..fa73eebc1ec 100644
--- a/doc/sag/sag-HLD.md
+++ b/doc/sag/sag-HLD.md
@@ -71,7 +71,7 @@ The VLAN interface will use static anycast gateway MAC address to replace CPU MA
The enable/disable knob on the VLAN interface can let user to determine to use CPU MAC or static anycast gateway MAC address.
In IPv6 link-local address management, the system MAC generated IPv6 link-local to me route is added by RouteOrch in its initialization.
-If the MAC address is changed between system and SAG, we need to call RouteOrch's API to delete old MAC gerenated IPv6 link-local to me route and then add new MAC generated IPv6 link-local to me route.
+If the MAC address is changed between system and SAG, we need to call RouteOrch's API to delete old MAC generated IPv6 link-local to me route and then add new MAC generated IPv6 link-local to me route.
The static anycast gateway on the VLAN interface will be disabled by default.
The following diagram describes the sequence between DBs and modules.
diff --git a/doc/sflow/sflow_hld.md b/doc/sflow/sflow_hld.md
index 1bd553ced6e..8591a1f7bc0 100644
--- a/doc/sflow/sflow_hld.md
+++ b/doc/sflow/sflow_hld.md
@@ -1,934 +1,934 @@
-# sFlow High Level Design
-### Rev 1.1
-## Table of Contents
-
-## 1. Revision
-Rev | Rev Date | Author | Change Description
----------|--------------|-----------|-------------------
-|v0.1 |05/01/2019 |Padmanabhan Narayanan | Initial version
-|v0.2 |05/20/2019 |Padmanabhan Narayanan | Updated based on internal review comments
-|v0.3 |06/11/2019 |Padmanabhan Narayanan | Update CLIs, remove sflowcfgd
-|v0.4 |06/17/2019 |Padmanabhan Narayanan | Add per-interface configurations, counter mode support and
unit test cases. Remove genetlink CLI
-|v0.5 |07/15/2019 |Padmanabhan Narayanan | Update CLI and DB schema based on comments from InMON :
Remove max-datagram-size from collector config
Add CLI for counter polling interval
Remvoe default header-size
Add "all" interfaces option
Separate CLI to set agent-id
-|v1.0 |09/13/2019 |Sudharsan | Updating sequence diagram for various CLIs
-|v1.1 |10/23/2019 |Padmanabhan Narayanan | Update SAI section to use SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME instead of ID. Note on genetlink creation. Change admin_state values to up/down instead of enable/disable to be consistent with management framework's sonic-common.yang.
-|v1.2 |03/07/2021 | Garrick He | Add VRF support and fix interface admin-status output.
-|v1.3 |01/24/2023 | Rajkumar (Marvell) | Add Egress Sflow support.
-## 2. Scope
-This document describes the high level design of sFlow in SONiC
-
-## 3. Definitions/Abbreviations
-
-Definitions/Abbreviation|Description
-------------------------|-----------
-SAI| Switch Abstraction Interface
-NOS| Network Operating System
-OID| OBject Identifier
-
-## 4. Overview
-
-sFlow (defined in https://sflow.org/sflow_version_5.txt) is a standard-based sampling technology the meets the key requirements of network traffic monitoring on switches and routers. sFlow uses two types of sampling:
-
-* Statistical packet-based sampling of switched or routed packet flows to provide visibility into network usage and active routes
-* Time-based sampling of interface counters.
-
-The sFlow monitoring system consists of:
-
- * sFlow Agents that reside in network equipment which gather network traffic and port counters and combines the flow samples and interface counters into sFlow datagrams and forwards them to the sFlow collector at regular intervals over a UDP socket. The datagrams consist of information on, but not limited to, packet header, ingress and egress interfaces, sampling parameters, and interface counters. A single sFlow datagram may contain samples from many flows.
- * sFlow collectors which receive and analyze the sFlow data.
-
- sFlow is an industry standard, low cost and scalable technique that enables a single analyzer to provide a network wide view.
-
-## 5. Requirements
-
-sFlow will be implemented in multiple phases:
-
-### **Phase I:**
-
-1. sFlow should be supported on physical interfaces.
-2. sFlow should support 2 sFlow collectors.
-3. sFlow collector IP can be either IPv4 or IPv6.
-4. sFlow collector can be reachable via
- 1. Front end port
- 2. Management port
-6. Default sFlow sample size should be set to 128 bytes.
-7. Support sFlow related
- 1. CLI show/config commands
- 2. syslogs
-8. sFlow counter support needed and config to change polling interval.
-
-### **Phase II:**
-1. Speed based sample rate setting (config sflow sample-rate speed...)
-2. sFlow should be supported on portchannel interfaces.
-2. Enhance CLI with session support (i.e create sessions add interfaces to specific sessions)
-3. SNMP support for sFlow.
-
-### **Phase III:**
-1. sFlow extended switch support.
-2. sFlow extended router support.
-
-### Not planned to be supported:
-1. sFlow backoff mechanism (Drop the packets beyond configured CPU Queue rate limit).
-2. sFlow over vlan interfaces.
-
-## 6. Module Design
-
-### 6.1 **Overall design**
-The following figure depicts the sFlow container in relation to the overall SONiC architecture:
-
-
-
-The CLI is enhanced to provide configuring and display of sFlow parameters including sflow collectors, agent IP, sampling rate for interfaces. The CLI configurations currently only interact with the CONFIG_DB.
-
-The newly introduced sflow container consists of:
-* An instantiation of the InMon's hsflowd daemon (https://github.com/sflow/host-sflow described in https://sflow.net/documentation.php). The hsflowd is launched as a systemctl service. The host-sflow is customised to interact with SONiC subsystems by introducing a host-sflow/src/Linux/mod_sonic.c (described later)
-* sflowmgrd : updates APP DB sFlow tables based on config updates
-
-The swss container is enhanced to add the following component:
-* sfloworch : which subscribes to the APP DB and acts as southbound interface to SAI for programming the SAI_SAMPLEPACKET sessions.
-* copporch : Copporch gets the genetlink family name and multicast group from copp.json file, programs the SAI genetlink attributes and associates it with trap group present for sflow in copp.json
-
-The syncd container is enhanced to support the SAI SAMPLEPACKET APIs.
-
-The ASIC drivers need to be enhanced to:
-* Associate the SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET to a specific genetlink channel and multicast group.
-* Punt trapped samples to this genetlink group
-
-The sflow container and changes to the existing components to support sflow are described in the following sections.
-
-### 6.2 **Configuration and control flow**
-The following figure shows the configuration and control flows for sFlow:
-
-
-
-1. The user configures the sflow collector, agent, sampling related parameters (interfaces to be sampled and rate) and these configurations are added to the CONFIG DB.
-2. The copporch (based on swssconfig/sample/00-copp.config.json) calls a SAI API that enables the ASIC driver to map the SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET trap to the specific genetlink channel and multicast group. The SAI driver creates the genetlink family and multicast group which will eventually be used to punt sFlow samples to hsflowd. If the SAI implementation uses the psample kernel driver (https://github.com/torvalds/linux/blob/master/net/psample/psample.c), the genetlink family "psample" and multicast group "packets" that the psample driver creates is to be used.
-3. The sflowmgrd daemon watches the CONFIG DB's SFLOW_COLLECTOR table and updates the /etc/hsflowd.conf which is the configuration file for hsflowd. Based on the nature of changes, the sflowmgrd may restart the hsflowd service. The hsflowd service uses the collector, UDP port and agent IP information to open sockets to reach the sFlow collectors.
-4. When hsflowd starts, the sonic module (mod_sonic) registered callback for packetBus/HSPEVENT_CONFIG_CHANGED opens a netlink socket for packet reception and registers an sflow sample handler over the netlink socket (HsflowdRx()).
-5. Sampling rate changes are updated in the SFLOW table. The sflowmgrd updates sampling rate changes into SFLOW_TABLE in the App DB. The sfloworch subagent in the orchagent container processes the change to propagate as corresponding SAI SAMPLEPACKET APIs.
-
-#### **Design Options**
-Current CLI command takes "sample-rate" as input.
-```
-"SFLOW_SESSION": {
- "Ethernet0": {
- "admin_state": "down"
- "sample_rate": "40000"
- },
-}
-```
-With introduction of egress sflow, we need to change above schema to take ingress and egress sampling rate from user.
-
-**Option 1 - Direction part of Key**
-
- "SFLOW_SESSION": {
- "Ethernet0|rx": {
- "admin_state": "down"
- "sample_rate": "40000"
- },
- "Ethernet0|tx": {
- "admin_state": "down"
- "sample_rate": "40000"
- },
- "Ethernet16|rx": {
- "admin_state": "up"
- "sample_rate": "32768"
- }
- }
-
-If user issues a "config sflow interface disable all", the SFLOW_SESSION will have the following:
-
-```
- "SFLOW_SESSION": {
- "all|rx":{
- "admin_state":"down"
- },
- ...
- }
-```
-If user issues a "config sflow interface disable all direction both", the SFLOW_SESSION will have the following:
-```
- "SFLOW_SESSION": {
- "all|rx":{
- "admin_state":"down"
- },
- "all|tx":{
- "admin_state":"down"
- },
- ...
- }
-```
-Pros:
-1) User can manage admin_status per tx/rx.
-
-
-Cons:
-1) Not align to openconfig model.
-2) New sub-level cli command inside interface hierarchy. Get admin-status and sample-rate at interface and direction level.
-
-Example:
-```
-localhost(config)# interface Ethernet 0
-localhost(conf-if-Ethernet0)# sflow direction rx
-localhost(conf-if-Ethernet0-sflow-rx)# enable
-localhost(conf-if-Ethernet0-sflow-rx)# sampling-rate 10000
-```
-
-**Option 2: Introduce ingress/egress sample rate**
-```
-"SFLOW_SESSION": {
- "Ethernet0": {
- "admin_state": "down"
- "ingress_sample_rate": "40000"
- "egress_sample_rate": "50000"
- }
-}
-```
-**NOTES:**
-
-- Single admin-state controls both rx and tx together.
-- In order for the administrator to disable sflow on a direction, administrator must set corresponding sampling-rate to 0.
-- If sample-rate is not set, sflowmgrd will set default sample-rate based on port speed.
-
-**Behavior on unsupported platforms:**
-- For platforms not supporting egress Sflow, add SAI capability query and save this capability in STATE_DB.
-- CLIs will validate this capability check. For example, if user configures egress sampling-rate on un-supported ASIC, cli will throw error.
-- sflowMgrd will query the capability and set egress-sampling rate to 0 in APP_DB.
-
-Pros:
-1) Align to openconfig model.
-
-**Option 3 - Introduce sample_direction at global and interface level**
-```
-"SFLOW": {
- "global": {
- "admin_state": "up"
- "polling_interval": "20"
- "agent_id": "loopback0",
- "sample_direction": "rx"
- }
- }
-
-"SFLOW_SESSION": {
- "Ethernet0": {
- "admin_state": "down"
- "sample_rate": "40000"
- "sample_direction": "both"
- }
-}
-
-```
-**NOTES:**
-
-- sample_direction command determines the sampling direction.
-- admin-state and sample-rate will be applicable only for the configured sample_direction.
-- sample_direction at interface-level has higher precedence then global configuration.
-- If sample_direction is not set, default is rx for backward compatibility.
-
-**Behavior on unsupported platforms:**
-- In init, query SAI egress sample capability and save this capability in STATE_DB.
-- CLIs will validate this capability check. For example, if user configures sample_direction as "tx" or "both" on un-supported ASIC, cli will throw error.
-- Similarly sflowOrch will also check the capability and set ASIC_DB only when supported.
-
-**Preferred Option 3**: Based on community feedback, this option is selected.
-
-Below figures explain the flow for different commands from CLI to SAI.
-
-In sflowOrch, APIs sflowAddPort()/sflowDelPort will take "direction" as additional argument. Based on egress sampling query-capability support, egress sample will be enabled on interface.
-
-
-
-
-
-
-
-
-
-
-
-
-
-### 6.3 **sFlow sample path**
-The following figure shows the sFlow sample packet path flow:
-
-
-
-1. The ASIC (DMAs) an sflow sample and interrupts the ASIC driver
-2. The ASIC driver ascertains that this is sample buffer that has been received as a result of sflow sampling being enabled for this interface.
-3. The ASIC driver checks that SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKETs are associated with a specific genetlink channel name and group. the ASIC driver encapsulates the sample in a genetlink buffer and adds the following netlink attributes to the sample : IIFINDEX, OIFINDEX, ORIGSIZE, SAMPLE, SAMPLE RATE. The genetlink buffer is sent via genlmsg_multicast().
-4. The hsflowd daemon's HsflowdRx() is waiting on the specific genetlink family name's multicast group id and receives the encapsulated sample. The HsflowdRx parses and extracts the encapsulated sflow attributes and injects the sample to the hsflowd packet thread using takeSample().
-5. The hsflowd packet thread accumulates sufficient samples and then constructs an sFlow UDP datagram and forwards to the configured sFlow collectors.
-
-### 6.4 **sFlow counters**
-
-The sFlow counter polling interval is set to 20 seconds. The pollBus/HSPEVENT_UPDATE_NIO callback caches the interface SAI OIDs during the first call by querying COUNTER_DB:COUNTERS_PORT_NAME_MAP. It periodically retrieves the COUNTER_DB interface counters and fills the necessary counters in hsflowd's SFLHost_nio_counters.
-
-### 6.5 **CLI**
-
-
-#### sFlow utility interface
-* sflow [options] {config | show} ...
-
- An sflow utility command is provided to operate with sflow configuration
- Also, the **config** and **show** commands would be extended to include the sflow option.
-
-#### Config commands
-
-* **sflow collector add** *{collector-name} {ipv4-address | ipv6-address}* [**--port** *{number}*]
-
- Where:
- * collector-name is the unique name of the sFlow collector
- * ipv4-address : IP address of the collector in dotted decimal format for IPv4
- * ipv6-address : x: x: x: x::x format for IPv6 address of the collector (where :: notation specifies successive hexadecimal fields of zeros)
- * port (OPTIONAL): specifies the UDP port of the collector (the range is from 0 to 65535. The default is 6343.)
- * vrf (OPTIONAL): specifies the VRF the collector is on. Only 'default' and 'mgmt' are supported (The default is 'default')
-
- Note:
- * A maximum of 2 collectors is allowed.
-
- * **sflow collector del** *{collector-name}*
-
- Delete the sflow collector with the given name
-
-* **sflow agent-id ** *{interface-name}*
-
- Where:
- * agent-id: specify the interface name whose ipv4 or ipv6 address will be used as the agent-id in sFlow datagrams.
-
- Note:
- * This setting is global (applicable to both collectors) and optional. Only a single agent-id is allowed. If agent-id is not specified (with this CLI), an appropriate IP that belongs to the switch is used as the agent-id based on some simple heuristics.
-
-* **sflow **
-
- Globally, sFlow is disabled by default. When sFlow is enabled globally, the sflow deamon is started and sampling will start on all interfaces which have sFlow enabled at the interface level (see “config sflow interface…”).
-When sflow is disabled globally, sampling is stopped on all relevant interfaces and sflow daemon is stopped.
-
-* **sflow sample-direction **
-
- This command takes global sflow sample direction. If not configured, default is "rx" for backward compatibility. Based on the direction, the sFlow is enabled at all the interface level at rx or tx or both.
-
-* **sflow interface ** *<{interface-name}|**all**>*
-
- Enable/disable sflow at an interface level. By default, sflow is enabled on all interfaces at the interface level. Use this command to explicitly disable sFlow for a specific interface. An interface is sampled if sflow is enabled globally as well as at the interface level.
-
- The “all” keyword is used as a convenience to enable/disable sflow at the interface level for all the interfaces.
-
- Note: The local configuration applied to an interface has higher precedence over the global configuration provided through the "all" keyword. If sample-direction is not set at interface level, it will configure direction "rx" irrespective of global configuraion. User needs to override the same with "config sflow interface sample-direction" command.
-
- This command enables sampling only in rx direction for backward compatibility.
-
-* **sflow interface sample-direction ** *<{interface-name}|**all**>*
-
- Set sample direction to determine ingress sampling or egress sampling or both. If not configured, default is "rx".
-
- Note: The local configuration applied to an interface has higher precedence over the global configuration provided through the "all" keyword.
-
-* **sflow interface sample-rate** *{interface-name} {value}*
-
- Configure the sample-rate for a specific interface.
-
- The default sample rate for any interface is (ifSpeed / 1e6) where ifSpeed is in bits/sec. So, the default sample rate based on interface speed is:
-
- * 1-in-1000 for a 1G link
- * 1-in-10,000 for a 10G link
- * 1-in-40,000 for a 40G link
- * 1-in-50,000 for a 50G link
- * 1-in-100,000 for a 100G link
- * 1-in-400,000 for a 400G link
-
- This default is chosen to allow the detection of a new flow of 10% link bandwidth in under 1 second. It is recommended not to change the defaults. This CLI is to be used only in case of exceptions (e.g., to set the sample-rate to the nearest power-of-2 if there are hardware restrictions in using the defaults)
-
- * value is the average number of packets skipped before the sample is taken. As per SAI samplepacket definition : "The sampling rate specifies random sampling probability as the ratio of packets observed to samples generated. For example a sampling rate of 256 specifies that, on average, 1 sample will be generated for every 256 packets observed."
- * Valid range 256:8388608.
-
- Note that on an interface, the sample-rate must be same in both tx and rx direction.
-
- If sample-direction is not set at interface level, it will configure direction "rx" irrespective of global configuraion. User needs to override the same with "config sflow interface sample-direction" command.
-
-
-* **sflow polling-interval** *{value}*
-
- The counter polling interval for all interfaces.
-
- * Valid range 0 or 5-300 seconds
- * Set polling-interval to 0 to disable
-
-* **sflow sample-rate speed <100M|1G|10G|25G|40G|50G|100G>** *{value}*
-
- Set the sampling-rate for interfaces based on speed:
- e.g.
- ```
- config sflow sample-rate speed 100M 250
- config sflow sample-rate speed 1G 500
- config sflow sample-rate speed 40G 5000
- ```
- * This will override the default speed based setting (which is ifSpeed / 1e6 where ifSpeed is in bits/sec.)
- * If port speed changes, this setting will be used to determine the updated sample-rate for the interface.
- * The config sflow interface sample-rate {interface-name} {value} setting can still be used to override the speed based setting for specific interfaces.
-
-
-#### Show commands
-
-* **show sflow**
- * Displays the current configuration, global defaults as well as user configured values including collectors.
-* **show sflow interface**
- * Displays the current running configuration of sflow interfaces.
-
-#### Example SONiC CLI configuration ####
-
-# sflow collector add collector1 10.100.12.13
-
-# sflow collector add collector2 10.144.1.2 --port 6344 --vrf mgmt
-
-# sflow agent-id add loopback0
-
-# sflow enable
-
-# sflow sample-direction both
-
-# sflow interface disable Ethernet0
-
-# sflow interface sample-direction Ethernet0 tx
-
-# sflow interface sample-rate Ethernet16 32768
-
-The configDB objects for the above CLI is given below:
-
-```
-{
- "SFLOW_COLLECTOR": {
- "collector1": {
- "collector_ip": "10.100.12.13",
- "collector_port": "6343"
- "collector_vrf": "default"
- },
- "collector2": {
- "collector_ip": "10.144.1.2",
- "collector_port": "6344"
- "collector_vrf": "mgmt"
- }
- },
-
- "SFLOW": {
- "global": {
- "admin_state": "up"
- "polling_interval": "20"
- "agent_id": "loopback0"
- "sample_direction": "both"
- }
- }
- "SFLOW_SESSION": {
- "Ethernet0": {
- "admin_state": "down"
- "sample_rate": "40000"
- "sample_direction": "tx"
- }
-}
-```
-
-# show sflow
-
-Displays the current configuration, global defaults as well as user configured values including collectors.
-
-```
-sFlow Global Information:
- sFlow Admin State: up
- sFlow Sample Direction: both
- sFlow Polling Interval: 0
- sFlow AgentID: default
-
- 2 Collectors configured:
- Name: prod IP addr: fe80::6e82:6aff:fe1e:cd8e UDP port: 6343 VRF: mgmt
- Name: ser5 IP addr: 172.21.35.15 UDP port: 6343 VRF: default
-
-
-```
-
-# show sflow interface
-
-Displays the current running configuration of sflow interfaces.
-```
-Interface Admin Status Sampling rate Sampling direction
---------- ------------ ------------- -------------------
-Ethernet0 down 40000 rx
-Ethernet1 up 25000 tx
-Ethernet2 up 40000 both
-Ethernet3 up 40000 both
-Ethernet4 up 40000 rx
-Ethernet5 up 40000 rx
-
-```
-
-### 6.6 **DB and Schema changes**
-
-#### ConfigDB Table & Schema
-
-A new SFLOW_COLLECTOR ConfigDB table entry would be added.
-```
-SFLOW_COLLECTOR|{{collector_name}}
- "collector_ip": {{ip_address}}
- "collector_port": {{ uint32 }} (OPTIONAL)
- "collector_vrf": {{string}}
-
-; Defines schema for sFlow collector configuration attributes
-key = SFLOW_COLLECTOR:collector_name ; sFlow collector configuration
-; field = value
-COLLECTOR_IP = IPv4address / IPv6address ; Ipv4 or IpV6 collector address
-COLLECTOR_PORT = 1*5DIGIT ; destination L4 port : a number between 0 and 65535
-COLLECTOR_VRF = "default" | "mgmt" ; the VRF for the collector, currently only 'default' and 'mgmt' is supported
-
-;value annotations
-collector_name = 1*16VCHAR
-```
-
-A new SFLOW table will be added which holds global configurations
-```
-; Defines schema for SFLOW table which holds global configurations
-key = SFLOW
-ADMIN_STATE = "up" / "down"
-POLLING_INTERVAL = 1*3DIGIT ; counter polling interval
-AGENT_ID = ifname ; Interface name
-SAMPLE_DIRECTION = "rx"/"tx"/"both" ; Sampling direction
-```
-
-A new SFLOW_SESSION table would be added.
-```
-key SFLOW_SESSION:interface_name
-ADMIN_STATE = "up" / "down"
-SAMPLE_RATE = 1*7DIGIT ; average number of packets skipped before the sample is taken
-SAMPLE_DIRECTION = "rx"/"tx"/"both" ; Sampling direction
-
-```
-
-#### AppDB & Schema
-
-A new SFLOW_SESSION_TABLE is added to the AppDB:
-
-```
-; Defines schema for SFLOW_SESSION_TABLE which holds global configurations
-key = SFLOW_SESSION_TABLE:interface_name
-ADMIN_STATE = "up" / "down"
-SAMPLE_RATE = 1*7DIGIT ; average number of packets skipped before the sample is taken
-SAMPLE_DIRECTION = "rx"/"tx"/"both" ; Sampling direction
-```
-
-A new SFLOW_SAMPLE_RATE_TABLE table which maps interface speed to the sample rate for that speed is added to the AppDB
-```
-; Defines schema for SFLOW_SAMPLE_RATE which maps interface speed to sampling rate
-key = SFLOW_SAMPLE_RATE_TABLE:speed
-SAMPLE_RATE = 1*7DIGIT ; average number of packets skipped before the sample is taken
-```
-Where speed = 1*6DIGIT ; port line speed in Mbps
-
-#### StateDB Schema
-Add "PORT_EGRESS_SAMPLE_CAPABLE" under swich capability.
-
-```
-"SWITCH_CAPABILITY|switch": {
- "value": {
- "PORT_EGRESS_SAMPLE_CAPABLE": "true"
- }
- }
-```
-#### **DB Migration**
-Since there is a change in schema for SFLOW and SFLOW_SESSION in config DB and SFLOW_SESSION_TABLE in APP DB, we will add support to migrate the entries to new schema in db_migrator.py. Default behavior would be append the existing entries with "sample_direction" with value "rx".
-
-
-Existing ConfigDB schema
-```
-"SFLOW": {
- "global": {
- "admin_state": "up",
- "polling_interval": "20",
- "agent_id": "loopback0"
- }
- }
-"SFLOW_SESSION": {
- "Ethernet0": {
- "admin_state": "down",
- "sample_rate": "40000"
- },
-}
-```
-After migration
-```
-"SFLOW": {
- "global": {
- "admin_state": "up",
- "polling_interval": "20",
- "agent_id": "loopback0",
- "sample_direction": "rx"
- }
- }
-"SFLOW_SESSION": {
- "Ethernet0": {
- "admin_state": "down",
- "sample_rate": "40000",
- "sample_direction": "rx"
- }
-}
-```
-**APP DB Migration**
-
-First-time when user migrates from non-supported to supported version.
-
-Before upgrade:
-```
- "SFLOW_TABLE:global": {
- "admin_state": "up"
- },
- "SFLOW_SESSION_TABLE:Ethernet6": {
- "admin_state": "up",
- "sample_rate": "1000"
- }
-
-```
-Post upgrade:
-```
-"SFLOW_TABLE:global": {
- "admin_state": "up",
- "sample_direction": "rx"
- },
- "SFLOW_SESSION_TABLE:Ethernet6": {
- "admin_state": "up",
- "sample_rate": "1000",
- "sample_direction": "rx"
- }
-
-```
-
-### 6.7 **sflow container**
-
-hsflowd (https://github.com/sflow/host-sflow) is the most popular open source implementation of the sFlow agent and provides support for DNS-SD (http://www.dns-sd.org/) and can be dockerised. hsflowd supports sFlow version 5 (https://sflow.org/sflow_version_5.txt which supersedes RFC 3176). hsflowd will run as a systemd service within the sflow docker.
-
-CLI configurations will be saved to the ConfigDB. Once the genetlink channel has been initialised and the sFlow traps mapped to the genetlink group, the hsflowd service is started. The service startup script will derive the /etc/hsflowd.conf from the ConfigDB. Config changes will necessitate restart of hsflowd. hsflowd provides the necessary statistics for the "show" commands. CLI "config" commands will retrieve the entries in the config DB.
-
-#### sflowmgrd
-
-The sflowmgrd consumes sflow config DB changes and updates the SFLOW APP DB tables.
-
-The sflowmgrd daemon listens to SFLOW_COLLECTOR to construct the hsflowd.conf and start the hsflowd service.
-The mapping between the SONiC sflow CLI parameters and the host-sflow is given below:
-
-SONIC CLI parameter| hsflowd.conf equivalent
--------------------|------------------------
-collector ip-address | collector.ip
-collector port| collector.UDPPort
-collecttor vrf| collector.vrf
-agent ip-address | agentIP
-max-datagram-size | datagramBytes
-sample-rate | sampling
-
-The master list of supported host-sflow tokens are found in host-sflow/src/Linux/hsflowtokens.h
-
-sflowmgrd also listens to SFLOW to propogate the sampling rate changes to App DB SFLOW_TABLE.
-
-#### hsflowd service
-
-hsflowd provides an module adaptation layer for interfacing with the NOS. In the host-sflow repo, a src/Linux/mod_sonic.c adaption layer will be provided for hsflowd APIs to SONiC that deal with hsflowd initialization, configuration changes, packet sample consumption etc. More specifically, SONiC will register and provide callbacks for the following HSP events:
-
-hsflowd bus/events|SONiC callback actions
-------------------|----------------------
- pollBus/HSPEVENT_INTF_READ | select all switchports for sampling by default
- pollBus/HSPEVENT_INTF_SPEED | set sampling rate
- pollBus/HSPEVENT_UPDATE_NIO | poll interface state from STATE_DB:PORT_TABLE and update counter stats in SFLHost_nio_counters from COUNTER DB
- pollBus/HSPEVENT_CONFIG_CHANGED)| Change sampling rate (/ port speed changed)
- packetBus/HSPEVENT_CONFIG_CHANGED | open netlink socket and register HsflowdRx()
-
-Refer to host-sflow/src/Linux/hsflowd.h for a list of events.
-
-### 6.8 **SWSS and syncd changes**
-
-### sFlowOrch
-
-An sFlowOrch is introduced in the Orchagent to handle configuration requests. The sFlowOrch essentially facilitates the creation/deletion of samplepacket sessions as well as get/set of session specific attributes. sFlowOrch sets the genetlink host interface that is to be used by the SAI driver to deliver the samples.
-
-Also, it monitors the SFLOW_SESSIONS_TABLE and PORT state to determine sampling rate / speed changes to derive and set the sampling rate for all the interfaces. Ingress/Egress Sampling is enabled on the interfaces based on direction setting. It uses the SAI samplepacket APIs to set each ports's sampling rate.
-
-### Rate limiting
-
-Considering that sFlow backoff mechanism is not being implemented, users should consider rate limiting sFlow samples using the currently existing COPP mechanism (the COPP config (e.g. src/sonic-swss/swssconfig/sample/00-copp.config.json) can include appropriate settings for the samplepacket trap and initialised using swssconfig).
-
-### 6.9 **SAI changes**
-
-Creating sFlow sessions and setting attributes (e.g. sampling rate) is described in SAI proposal : https://github.com/opencomputeproject/SAI/tree/master/doc/Samplepacket
-
-As per the sFlow specification, each packet sample should have certain minimal meta data for processing by the sFlow analyser. The psample infrastructure (http://man7.org/linux/man-pages/man8/tc-sample.8.html) already describes the desired metadata fields (which the SAI driver needs to add to each sample):
-
-```
-SAMPLED PACKETS METADATA FIELDS
- The metadata are delivered to userspace applications using the
- psample generic netlink channel, where each sample includes the
- following netlink attributes:
-
- PSAMPLE_ATTR_IIFINDEX
- The input interface index of the packet, if there is one.
-
- PSAMPLE_ATTR_OIFINDEX
- The output interface index of the packet. This field is not
- relevant on ingress sampling
-
- PSAMPLE_ATTR_ORIGSIZE
- The size of the original packet (before truncation)
-
- PSAMPLE_ATTR_SAMPLE_GROUP
- The psample group the packet was sent to
-
- PSAMPLE_ATTR_GROUP_SEQ
- A sequence number of the sampled packet. This number is
- incremented with each sampled packet of the current psample
- group
-
- PSAMPLE_ATTR_SAMPLE_RATE
- The rate the packet was sampled with
-```
-
-The SAI driver may provide the interface OIDs corresponding to the IIFINDEX AND OIFINDEX. The hsflowd mod_sonic HsflowdRx() may have to map these correspondingly to the netdev ifindex. Note that the default PSAMPLE_ATTR_SAMPLE_GROUP that hsflowd expects is 1 for ingress and 2 for egress.
-
-Depending on platform capabilities, SAI driver may report additional attributes defined in https://github.com/torvalds/linux/blob/master/include/uapi/linux/psample.h. For example, PSAMPLE_ATTR_OUT_TC (egress queue), PSAMPLE_ATTR_OUT_TC_OCC (egress queue depth), and PSAMPLE_ATTR_LATENCY (transit delay) populate the sFlow Transit Delay Structures (https://sflow.org/sflow_transit.txt).
-
-Rather than define a new framework for describing the metadata for sFlow use, SAI would re-use the framework that the psample driver (https://github.com/torvalds/linux/blob/master/net/psample/psample.c) currently uses. The psample kernel driver is based on the Generic Netlink subsystem that is described in https://wiki.linuxfoundation.org/networking/generic_netlink_howto. SAI ASIC drivers supporting sFlow may choose to use the psample.ko driver as-is or may choose to implement the generic netlink interface (that complies with the above listed metadata) using a private generic netlink family.
-
-#### SAI Host Interface based on Generic Netlink
-
-During SWSS init (as part of copporch), based on the swssconfig/sample/00-copp.config.json settings, sai_create_hostif_fn() is used to let the SAI driver create a special genetlink interface (type SAI_HOST_INTERFACE_TYPE_GENETLINK) and associate it with generic netlink family (SAI_HOST_INTERFACE_ATTR_NAME) and multicast group name (SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME). Later, sai_create_hostif_table_entry_fn() is used to map SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET to the genetlink sai_host_if.
-
-syncd/SAI implementations can use one of the following methods to create the genetlink interface:
-
-1. As part of syncd/SAI driver init, a driver based on the standard psample driver (genetlink family ="psample" and multicast group "packets") may be installed which would create the genetlink. In this case the sai_create_hostif_fn() determines that the genetlink interface is already created and merely associates the sai_host_if to the genetlink.
-
-2. The genetlink interface may alternatively be created during the call to sai_create_hostif_fn().
-
-
-#### Changes in SAI to support the GENETLINK host interface
-
-The changes in SAI to support the GENETLINK host interface is highlighted below:
-
-```
- /** Generic netlink */
- SAI_HOSTIF_TYPE_GENETLINK
-
- /**
- * @brief Name [char[SAI_HOSTIF_NAME_SIZE]]
- *
- * The maximum number of characters for the name is SAI_HOSTIF_NAME_SIZE - 1 since
- * it needs the terminating null byte ('\0') at the end.
- *
- * In case of GENETLINK, name refers to the genl family name
- *
- * @type char
- * @flags MANDATORY_ON_CREATE | CREATE_ONLY
- * @condition SAI_HOSTIF_ATTR_TYPE == SAI_HOSTIF_TYPE_NETDEV or SAI_HOSTIF_ATTR_TYPE == SAI_HOSTIF_TYPE_GENETLINK
- */
- SAI_HOSTIF_ATTR_NAME,
-
- /**
- * @brief Name [char[SAI_HOSTIF_GENETLINK_MCGRP_NAME_SIZE]]
- *
- * The maximum number of characters for the name is SAI_HOSTIF_GENETLINK_MCGRP_NAME_SIZE - 1
- * Set the Generic netlink multicast group name on which the packets/buffers
- * are received on this host interface
- *
- * @type char
- * @flags MANDATORY_ON_CREATE | CREATE_ONLY
- * @condition SAI_HOSTIF_ATTR_TYPE == SAI_HOSTIF_TYPE_GENETLINK
- */
- SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME,
-
- /** Receive packets via Linux generic netlink interface */
- SAI_HOSTIF_TABLE_ENTRY_CHANNEL_TYPE_GENETLINK
-```
-#### Creating a GENETLINK Host Interface
-
-Below is an example code snip that shows how a GENETLINK based host inerface is created. It is assumed that the application has already installed the psample.ko and created multicast group 100.
-
-```
-// Create a Host Interface based on generic netlink
-sai_object_id_t host_if_id;
-sai_attribute_t sai_host_if_attr[3];
-
-sai_host_if_attr[0].id=SAI_HOST_INTERFACE_ATTR_TYPE;
-sai_host_if_attr[0].value=SAI_HOST_INTERFACE_TYPE_GENETLINK;
-
-sai_host_if_attr[1].id= SAI_HOST_INTERFACE_ATTR_NAME;
-sai_host_if_attr[1].value="psample";
-
-sai_host_if_attr[2].id= SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME;
-sai_host_if_attr[2].value="packets";
-
-sai_create_host_interface_fn(&host_if_id, 9, sai_host_if_attr);
-```
-
-### Mapping a sFlow (SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET) trap to a GENETLINK host interface multicast group id
-
-Below is the code snip that outlines how an sFlow trap is mapped to the GENETLINK host interface created in the previous section.
-
-```
-// Configure the host table to receive traps on the generic netlink socket
-
-sai_object_id_t host_table_entry;
-sai_attribute_t sai_host_table_attr[9];
-
-sai_host_table_attr[0].id=SAI_HOSTIF_TABLE_ENTRY_ATTR_TYPE;
-sai_host_table_attr[0].value= SAI_HOST_INTERFACE_TABLE_ENTRY_TYPE_TRAP_ID;
-
-sai_host_table_attr[1].id= SAI_HOSTIF_TABLE_ENTRY_ATTR_TRAP_ID;
-sai_host_table_attr[1].value=sflow_trap_id; // Object referencing SAMPLEPACKET trap
-
-sai_host_table_attr[2].id= SAI_HOSTIF_TABLE_ENTRY_ATTR_CHANNEL;
-sai_host_table_attr[2].value= SAI_HOSTIF_TABLE_ENTRY_CHANNEL_TYPE_GENETLINK;
-
-sai_host_table_attr[3].id= SAI_HOSTIF_TABLE_ENTRY_ATTR_HOST_IF;
-sai_host_table_attr[3].value=host_if_id; // host interface of type file descriptor for GENETLINK
-
-sai_create_hostif_table_entry_fn(&host_table_entry, 4, sai_host_table_attr);
-```
-
-It is assumed that the trap group and the trap itself have been defined using sai_create_hostif_trap_group_fn() and sai_create_hostif_trap_fn().
-
-#### SAI capability query for Sflow
-```
- sai_attr_capability_t capability;
-// Ingress Sflow capability query
-status = sai_query_attribute_capability(gSwitchId, SAI_OBJECT_TYPE_PORT, SAI_PORT_ATTR_INGRESS_SAMPLEPACKET_ENABLE, &capability);
-
-// Egress Sflow capability query
-status = sai_query_attribute_capability(gSwitchId, SAI_OBJECT_TYPE_PORT, SAI_PORT_ATTR_EGRESS_SAMPLEPACKET_ENABLE, &capability);
-```
-#### Mapping of Sflow to interface
-```
-// Ingress Sflow mapped to "ingress-sample" rate.
-attr.id = SAI_PORT_ATTR_INGRESS_SAMPLEPACKET_ENABLE;
-attr.value.oid = sample_id;
-set_port_attribute(port_id, &attr);
-
-// Egress Sflow mapped to direction "egress-sample" rate.
-attr.id = SAI_PORT_ATTR_EGRESS_SAMPLEPACKET_ENABLE;
-attr.value.oid = sample_id;
-set_port_attribute(port_id, &attr);
-
-```
-## 7 **CLI Yang Model**
-```
-diff --git a/src/sonic-yang-models/yang-models/sonic-sflow.yang b/src/sonic-yang-models/yang-models/sonic-sflow.yang
-index 62984f064..601d112fd 100644
---- a/src/sonic-yang-models/yang-models/sonic-sflow.yang
-+++ b/src/sonic-yang-models/yang-models/sonic-sflow.yang
-@@ -28,10 +28,28 @@ module sonic-sflow{
-
- description "SFLOW yang Module for SONiC OS";
-
-+ revision 2023-03-14 {
-+ description "Add direction command to support egress sflow";
-+ }
-+
- revision 2021-04-26 {
- description "First Revision";
- }
-
-+ typedef sample_direction {
-+ type enumeration {
-+ enum rx {
-+ description "rx direction";
-+ }
-+ enum tx {
-+ description "tx direction";
-+ }
-+ enum both {
-+ description "Both tx and rx direction";
-+ }
-+ }
-+ }
-+
- container sonic-sflow {
-
- container SFLOW_COLLECTOR {
-@@ -89,6 +107,13 @@ module sonic-sflow{
- }
- description "Sets the packet sampling rate. The rate is expressed as an integer N, where the intended sampling rate is 1/N packets.";
- }
-+
-+ leaf sample_direction {
-+ type sample_direction;
-+ default "rx";
-+ description "sflow sample direction"
-+ }
-+
- } /* end of list SFLOW_SESSION_LIST */
- } /* end of container SFLOW_SESSION */
-
-@@ -133,6 +158,13 @@ module sonic-sflow{
- }
- description "Interface name";
- }
-+
-+ leaf sample_direction {
-+ type sample_direction;
-+ default "rx";
-+ description "sflow sample direction"
-+ }
-+
- } /* end of container global */
- } /* end of container SFLOW */
-
-```
-## 8 **Warmboot support**
-
-sFlow packet/counter sampling should not be affected after a warm reboot. In case of a planned warm reboot, packet sampling will be stopped.
-
-## 9 **sFlow in Virtual Switch**
-
-On the SONiC VS, SAI calls would map to the tc_sample commands on the switchport interfaces (http://man7.org/linux/man-pages/man8/tc-sample.8.html).
-
-## 10 **Build**
-
-* The host-sflow package will be built with the mod_sonic callback implementations using the FEATURES="SONIC" option
-
-## 11 **Restrictions**
-* /etc/hsflowd.conf should not be modified manually. While it should be possible to change /etc/hsflowd.conf manually and restart the sflow container, it is not recommended.
-* configuration updates will necessitate hsflowd service restart
-* hsflowd daemon will initialize only after receiving the SYSTEM_READY|SYSTEM_STATE Status=Up from SONiC. The system ready state however depends on all the monitored daemons to be ready. Failure on any of these, will result in system state to be down. In such scenarios, sflow will wait until 180 seconds and if system ready is not up will proceed with initialization. For system ready feature please visit https://github.com/sonic-net/SONiC/blob/master/doc/system_health_monitoring/system-ready-HLD.md
-
-## 12 **Unit Test cases**
-Unit test case one-liners are given below:
-
-| S.No | Test case synopsis |
-|------|-----------------------------------------------------------------------------------------------------------------------------------------|
-| 1 | Verify that the SFLOW_COLLECTOR configuration additions from CONFIG_DB are processed by hsflowd. |
-| 2 | Verify that the SFLOW_COLLECTOR configuration deletions from CONFIG_DB are processed by hsflowd. |
-| 3 | Verify that sFlowOrch creates "psample" multicast group "packets" if there is not psample driver inserted. |
-| 4 | Verify that sFlowOrch maps SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET trap to the "psample" family and multicast group "packets". |
-| 5 | Verify that it is possible to enable and disable sflow using the SFLOW table's admin_state field in CONFIG_DB |
-| 6 | Verify that interfaces can be enabled/disabled using additions/deletions in SFLOW_SESSION table. |
-| 7 | Verify that it is possible to change the counter polling interval using the SFLOW table in CONFIG_DB |
-| 8 | Verify that it is possible to change the agent-id using the SFLOW table in CONFIG_DB
-| 9 | Verify that it is possible to change the sampling rate per interface using SFLOW_SESSION interface sample_rate field for direction tx, rx and both in CONFIG_DB |
-| 10 | Verify that changes to SFLOW_SESSION CONFIG_DB entry is pushed to the corresponding table in APP_DB and to ASIC_DB by sFlowOrch |
-| 11 | Verify that collector and per-interface changes get reflected using the "show sflow" and "show sflow interface" commands |
-| 12 | Verify that packet samples are coming into hsflowd agent as per the global and per-interface configuration |
-| 13 | Verify that the hsflowd generated UDP datagrams are generated as expected and contain all the PSAMPLE_ATTR* attributes in the meta data |
-| 14 | Verify that samples are received when either 1 or 2 collectors are configured. |
-| 15 | Verify the sample collection for both IPv4 and IPv6 collectors. |
-| 16 | Verify that sample collection works on all ports or on a subset of ports (using lowest possible sampling rate). |
-| 17 | Verify that counter samples are updated every 20 seconds |
-| 18 | Verify that packet & counter samples stop for a disabled interface. |
-| 19 | Verify that sampling changes based on interface speed and per-interface and direction sampling rate change. Validate for sample-direction rx,txand both. |
-| 20 | Verify that if sFlow is not enabled in the build, the sflow docker is not started |
-| 21 | Verify that sFlow docker can be stopped and restarted and check that packet and counter sampling restarts. |
-| 22 | Verify that with config saved in the config_db.json, restarting the unit should result in sFlow coming up with saved configuration. |
-| 23 | Verify sFlow functionality with valid startup configuration and after a normal reboot, fast-boot and warm-boot. |
-| 24 | Verify that the sFlow hsflowd logs are emitted to the syslog file for various severities. |
-| 25 | Verify that the swss restart works without issues when sflow is enabled and continues to sample as configured. |
-| 26 | Verify that collector functions properly on 'default' VRF and can send counter and flow samples |
-| 27 | Verify that collector functions properly on 'mgmt' VRF and can send counter and flow samples |
-| 28 | Verify that egress sampling is applied based on query-capability. |
-|29 | Verify CONFIG DB migration changes for SFLOW SESSION table for old to new schema
-|30 | Verify APP DB migration changes for SFLOW SESSION table for old to new schema
-
-## 13 **System Testcase**
-New ptf test cases will be added for this feature.
-
-## 14 **Action items**
-* Determine if it is possible to change configuration without restarting hsflowd
-* Check host-sflow licensing options
-* Change hsflowd to version 2.0.45-1 for accpeting egress samples.
+# sFlow High Level Design
+### Rev 1.1
+## Table of Contents
+
+## 1. Revision
+Rev | Rev Date | Author | Change Description
+---------|--------------|-----------|-------------------
+|v0.1 |05/01/2019 |Padmanabhan Narayanan | Initial version
+|v0.2 |05/20/2019 |Padmanabhan Narayanan | Updated based on internal review comments
+|v0.3 |06/11/2019 |Padmanabhan Narayanan | Update CLIs, remove sflowcfgd
+|v0.4 |06/17/2019 |Padmanabhan Narayanan | Add per-interface configurations, counter mode support and
unit test cases. Remove genetlink CLI
+|v0.5 |07/15/2019 |Padmanabhan Narayanan | Update CLI and DB schema based on comments from InMON :
Remove max-datagram-size from collector config
Add CLI for counter polling interval
Remove default header-size
Add "all" interfaces option
Separate CLI to set agent-id
+|v1.0 |09/13/2019 |Sudharsan | Updating sequence diagram for various CLIs
+|v1.1 |10/23/2019 |Padmanabhan Narayanan | Update SAI section to use SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME instead of ID. Note on genetlink creation. Change admin_state values to up/down instead of enable/disable to be consistent with management framework's sonic-common.yang.
+|v1.2 |03/07/2021 | Garrick He | Add VRF support and fix interface admin-status output.
+|v1.3 |01/24/2023 | Rajkumar (Marvell) | Add Egress Sflow support.
+## 2. Scope
+This document describes the high level design of sFlow in SONiC
+
+## 3. Definitions/Abbreviations
+
+Definitions/Abbreviation|Description
+------------------------|-----------
+SAI| Switch Abstraction Interface
+NOS| Network Operating System
+OID| OBject Identifier
+
+## 4. Overview
+
+sFlow (defined in https://sflow.org/sflow_version_5.txt) is a standard-based sampling technology the meets the key requirements of network traffic monitoring on switches and routers. sFlow uses two types of sampling:
+
+* Statistical packet-based sampling of switched or routed packet flows to provide visibility into network usage and active routes
+* Time-based sampling of interface counters.
+
+The sFlow monitoring system consists of:
+
+ * sFlow Agents that reside in network equipment which gather network traffic and port counters and combines the flow samples and interface counters into sFlow datagrams and forwards them to the sFlow collector at regular intervals over a UDP socket. The datagrams consist of information on, but not limited to, packet header, ingress and egress interfaces, sampling parameters, and interface counters. A single sFlow datagram may contain samples from many flows.
+ * sFlow collectors which receive and analyze the sFlow data.
+
+ sFlow is an industry standard, low cost and scalable technique that enables a single analyzer to provide a network wide view.
+
+## 5. Requirements
+
+sFlow will be implemented in multiple phases:
+
+### **Phase I:**
+
+1. sFlow should be supported on physical interfaces.
+2. sFlow should support 2 sFlow collectors.
+3. sFlow collector IP can be either IPv4 or IPv6.
+4. sFlow collector can be reachable via
+ 1. Front end port
+ 2. Management port
+6. Default sFlow sample size should be set to 128 bytes.
+7. Support sFlow related
+ 1. CLI show/config commands
+ 2. syslogs
+8. sFlow counter support needed and config to change polling interval.
+
+### **Phase II:**
+1. Speed based sample rate setting (config sflow sample-rate speed...)
+2. sFlow should be supported on portchannel interfaces.
+2. Enhance CLI with session support (i.e create sessions add interfaces to specific sessions)
+3. SNMP support for sFlow.
+
+### **Phase III:**
+1. sFlow extended switch support.
+2. sFlow extended router support.
+
+### Not planned to be supported:
+1. sFlow backoff mechanism (Drop the packets beyond configured CPU Queue rate limit).
+2. sFlow over vlan interfaces.
+
+## 6. Module Design
+
+### 6.1 **Overall design**
+The following figure depicts the sFlow container in relation to the overall SONiC architecture:
+
+
+
+The CLI is enhanced to provide configuring and display of sFlow parameters including sflow collectors, agent IP, sampling rate for interfaces. The CLI configurations currently only interact with the CONFIG_DB.
+
+The newly introduced sflow container consists of:
+* An instantiation of the InMon's hsflowd daemon (https://github.com/sflow/host-sflow described in https://sflow.net/documentation.php). The hsflowd is launched as a systemctl service. The host-sflow is customised to interact with SONiC subsystems by introducing a host-sflow/src/Linux/mod_sonic.c (described later)
+* sflowmgrd : updates APP DB sFlow tables based on config updates
+
+The swss container is enhanced to add the following component:
+* sfloworch : which subscribes to the APP DB and acts as southbound interface to SAI for programming the SAI_SAMPLEPACKET sessions.
+* copporch : Copporch gets the genetlink family name and multicast group from copp.json file, programs the SAI genetlink attributes and associates it with trap group present for sflow in copp.json
+
+The syncd container is enhanced to support the SAI SAMPLEPACKET APIs.
+
+The ASIC drivers need to be enhanced to:
+* Associate the SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET to a specific genetlink channel and multicast group.
+* Punt trapped samples to this genetlink group
+
+The sflow container and changes to the existing components to support sflow are described in the following sections.
+
+### 6.2 **Configuration and control flow**
+The following figure shows the configuration and control flows for sFlow:
+
+
+
+1. The user configures the sflow collector, agent, sampling related parameters (interfaces to be sampled and rate) and these configurations are added to the CONFIG DB.
+2. The copporch (based on swssconfig/sample/00-copp.config.json) calls a SAI API that enables the ASIC driver to map the SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET trap to the specific genetlink channel and multicast group. The SAI driver creates the genetlink family and multicast group which will eventually be used to punt sFlow samples to hsflowd. If the SAI implementation uses the psample kernel driver (https://github.com/torvalds/linux/blob/master/net/psample/psample.c), the genetlink family "psample" and multicast group "packets" that the psample driver creates is to be used.
+3. The sflowmgrd daemon watches the CONFIG DB's SFLOW_COLLECTOR table and updates the /etc/hsflowd.conf which is the configuration file for hsflowd. Based on the nature of changes, the sflowmgrd may restart the hsflowd service. The hsflowd service uses the collector, UDP port and agent IP information to open sockets to reach the sFlow collectors.
+4. When hsflowd starts, the sonic module (mod_sonic) registered callback for packetBus/HSPEVENT_CONFIG_CHANGED opens a netlink socket for packet reception and registers an sflow sample handler over the netlink socket (HsflowdRx()).
+5. Sampling rate changes are updated in the SFLOW table. The sflowmgrd updates sampling rate changes into SFLOW_TABLE in the App DB. The sfloworch subagent in the orchagent container processes the change to propagate as corresponding SAI SAMPLEPACKET APIs.
+
+#### **Design Options**
+Current CLI command takes "sample-rate" as input.
+```
+"SFLOW_SESSION": {
+ "Ethernet0": {
+ "admin_state": "down"
+ "sample_rate": "40000"
+ },
+}
+```
+With introduction of egress sflow, we need to change above schema to take ingress and egress sampling rate from user.
+
+**Option 1 - Direction part of Key**
+
+ "SFLOW_SESSION": {
+ "Ethernet0|rx": {
+ "admin_state": "down"
+ "sample_rate": "40000"
+ },
+ "Ethernet0|tx": {
+ "admin_state": "down"
+ "sample_rate": "40000"
+ },
+ "Ethernet16|rx": {
+ "admin_state": "up"
+ "sample_rate": "32768"
+ }
+ }
+
+If user issues a "config sflow interface disable all", the SFLOW_SESSION will have the following:
+
+```
+ "SFLOW_SESSION": {
+ "all|rx":{
+ "admin_state":"down"
+ },
+ ...
+ }
+```
+If user issues a "config sflow interface disable all direction both", the SFLOW_SESSION will have the following:
+```
+ "SFLOW_SESSION": {
+ "all|rx":{
+ "admin_state":"down"
+ },
+ "all|tx":{
+ "admin_state":"down"
+ },
+ ...
+ }
+```
+Pros:
+1) User can manage admin_status per tx/rx.
+
+
+Cons:
+1) Not align to openconfig model.
+2) New sub-level cli command inside interface hierarchy. Get admin-status and sample-rate at interface and direction level.
+
+Example:
+```
+localhost(config)# interface Ethernet 0
+localhost(conf-if-Ethernet0)# sflow direction rx
+localhost(conf-if-Ethernet0-sflow-rx)# enable
+localhost(conf-if-Ethernet0-sflow-rx)# sampling-rate 10000
+```
+
+**Option 2: Introduce ingress/egress sample rate**
+```
+"SFLOW_SESSION": {
+ "Ethernet0": {
+ "admin_state": "down"
+ "ingress_sample_rate": "40000"
+ "egress_sample_rate": "50000"
+ }
+}
+```
+**NOTES:**
+
+- Single admin-state controls both rx and tx together.
+- In order for the administrator to disable sflow on a direction, administrator must set corresponding sampling-rate to 0.
+- If sample-rate is not set, sflowmgrd will set default sample-rate based on port speed.
+
+**Behavior on unsupported platforms:**
+- For platforms not supporting egress Sflow, add SAI capability query and save this capability in STATE_DB.
+- CLIs will validate this capability check. For example, if user configures egress sampling-rate on un-supported ASIC, cli will throw error.
+- sflowMgrd will query the capability and set egress-sampling rate to 0 in APP_DB.
+
+Pros:
+1) Align to openconfig model.
+
+**Option 3 - Introduce sample_direction at global and interface level**
+```
+"SFLOW": {
+ "global": {
+ "admin_state": "up"
+ "polling_interval": "20"
+ "agent_id": "loopback0",
+ "sample_direction": "rx"
+ }
+ }
+
+"SFLOW_SESSION": {
+ "Ethernet0": {
+ "admin_state": "down"
+ "sample_rate": "40000"
+ "sample_direction": "both"
+ }
+}
+
+```
+**NOTES:**
+
+- sample_direction command determines the sampling direction.
+- admin-state and sample-rate will be applicable only for the configured sample_direction.
+- sample_direction at interface-level has higher precedence then global configuration.
+- If sample_direction is not set, default is rx for backward compatibility.
+
+**Behavior on unsupported platforms:**
+- In init, query SAI egress sample capability and save this capability in STATE_DB.
+- CLIs will validate this capability check. For example, if user configures sample_direction as "tx" or "both" on un-supported ASIC, cli will throw error.
+- Similarly sflowOrch will also check the capability and set ASIC_DB only when supported.
+
+**Preferred Option 3**: Based on community feedback, this option is selected.
+
+Below figures explain the flow for different commands from CLI to SAI.
+
+In sflowOrch, APIs sflowAddPort()/sflowDelPort will take "direction" as additional argument. Based on egress sampling query-capability support, egress sample will be enabled on interface.
+
+
+
+
+
+
+
+
+
+
+
+
+
+### 6.3 **sFlow sample path**
+The following figure shows the sFlow sample packet path flow:
+
+
+
+1. The ASIC (DMAs) an sflow sample and interrupts the ASIC driver
+2. The ASIC driver ascertains that this is sample buffer that has been received as a result of sflow sampling being enabled for this interface.
+3. The ASIC driver checks that SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKETs are associated with a specific genetlink channel name and group. the ASIC driver encapsulates the sample in a genetlink buffer and adds the following netlink attributes to the sample : IIFINDEX, OIFINDEX, ORIGSIZE, SAMPLE, SAMPLE RATE. The genetlink buffer is sent via genlmsg_multicast().
+4. The hsflowd daemon's HsflowdRx() is waiting on the specific genetlink family name's multicast group id and receives the encapsulated sample. The HsflowdRx parses and extracts the encapsulated sflow attributes and injects the sample to the hsflowd packet thread using takeSample().
+5. The hsflowd packet thread accumulates sufficient samples and then constructs an sFlow UDP datagram and forwards to the configured sFlow collectors.
+
+### 6.4 **sFlow counters**
+
+The sFlow counter polling interval is set to 20 seconds. The pollBus/HSPEVENT_UPDATE_NIO callback caches the interface SAI OIDs during the first call by querying COUNTER_DB:COUNTERS_PORT_NAME_MAP. It periodically retrieves the COUNTER_DB interface counters and fills the necessary counters in hsflowd's SFLHost_nio_counters.
+
+### 6.5 **CLI**
+
+
+#### sFlow utility interface
+* sflow [options] {config | show} ...
+
+ An sflow utility command is provided to operate with sflow configuration
+ Also, the **config** and **show** commands would be extended to include the sflow option.
+
+#### Config commands
+
+* **sflow collector add** *{collector-name} {ipv4-address | ipv6-address}* [**--port** *{number}*]
+
+ Where:
+ * collector-name is the unique name of the sFlow collector
+ * ipv4-address : IP address of the collector in dotted decimal format for IPv4
+ * ipv6-address : x: x: x: x::x format for IPv6 address of the collector (where :: notation specifies successive hexadecimal fields of zeros)
+ * port (OPTIONAL): specifies the UDP port of the collector (the range is from 0 to 65535. The default is 6343.)
+ * vrf (OPTIONAL): specifies the VRF the collector is on. Only 'default' and 'mgmt' are supported (The default is 'default')
+
+ Note:
+ * A maximum of 2 collectors is allowed.
+
+ * **sflow collector del** *{collector-name}*
+
+ Delete the sflow collector with the given name
+
+* **sflow agent-id ** *{interface-name}*
+
+ Where:
+ * agent-id: specify the interface name whose ipv4 or ipv6 address will be used as the agent-id in sFlow datagrams.
+
+ Note:
+ * This setting is global (applicable to both collectors) and optional. Only a single agent-id is allowed. If agent-id is not specified (with this CLI), an appropriate IP that belongs to the switch is used as the agent-id based on some simple heuristics.
+
+* **sflow **
+
+ Globally, sFlow is disabled by default. When sFlow is enabled globally, the sflow daemon is started and sampling will start on all interfaces which have sFlow enabled at the interface level (see “config sflow interface…”).
+When sflow is disabled globally, sampling is stopped on all relevant interfaces and sflow daemon is stopped.
+
+* **sflow sample-direction **
+
+ This command takes global sflow sample direction. If not configured, default is "rx" for backward compatibility. Based on the direction, the sFlow is enabled at all the interface level at rx or tx or both.
+
+* **sflow interface ** *<{interface-name}|**all**>*
+
+ Enable/disable sflow at an interface level. By default, sflow is enabled on all interfaces at the interface level. Use this command to explicitly disable sFlow for a specific interface. An interface is sampled if sflow is enabled globally as well as at the interface level.
+
+ The “all” keyword is used as a convenience to enable/disable sflow at the interface level for all the interfaces.
+
+ Note: The local configuration applied to an interface has higher precedence over the global configuration provided through the "all" keyword. If sample-direction is not set at interface level, it will configure direction "rx" irrespective of global configuration. User needs to override the same with "config sflow interface sample-direction" command.
+
+ This command enables sampling only in rx direction for backward compatibility.
+
+* **sflow interface sample-direction ** *<{interface-name}|**all**>*
+
+ Set sample direction to determine ingress sampling or egress sampling or both. If not configured, default is "rx".
+
+ Note: The local configuration applied to an interface has higher precedence over the global configuration provided through the "all" keyword.
+
+* **sflow interface sample-rate** *{interface-name} {value}*
+
+ Configure the sample-rate for a specific interface.
+
+ The default sample rate for any interface is (ifSpeed / 1e6) where ifSpeed is in bits/sec. So, the default sample rate based on interface speed is:
+
+ * 1-in-1000 for a 1G link
+ * 1-in-10,000 for a 10G link
+ * 1-in-40,000 for a 40G link
+ * 1-in-50,000 for a 50G link
+ * 1-in-100,000 for a 100G link
+ * 1-in-400,000 for a 400G link
+
+ This default is chosen to allow the detection of a new flow of 10% link bandwidth in under 1 second. It is recommended not to change the defaults. This CLI is to be used only in case of exceptions (e.g., to set the sample-rate to the nearest power-of-2 if there are hardware restrictions in using the defaults)
+
+ * value is the average number of packets skipped before the sample is taken. As per SAI samplepacket definition : "The sampling rate specifies random sampling probability as the ratio of packets observed to samples generated. For example a sampling rate of 256 specifies that, on average, 1 sample will be generated for every 256 packets observed."
+ * Valid range 256:8388608.
+
+ Note that on an interface, the sample-rate must be same in both tx and rx direction.
+
+ If sample-direction is not set at interface level, it will configure direction "rx" irrespective of global configuration. User needs to override the same with "config sflow interface sample-direction" command.
+
+
+* **sflow polling-interval** *{value}*
+
+ The counter polling interval for all interfaces.
+
+ * Valid range 0 or 5-300 seconds
+ * Set polling-interval to 0 to disable
+
+* **sflow sample-rate speed <100M|1G|10G|25G|40G|50G|100G>** *{value}*
+
+ Set the sampling-rate for interfaces based on speed:
+ e.g.
+ ```
+ config sflow sample-rate speed 100M 250
+ config sflow sample-rate speed 1G 500
+ config sflow sample-rate speed 40G 5000
+ ```
+ * This will override the default speed based setting (which is ifSpeed / 1e6 where ifSpeed is in bits/sec.)
+ * If port speed changes, this setting will be used to determine the updated sample-rate for the interface.
+ * The config sflow interface sample-rate {interface-name} {value} setting can still be used to override the speed based setting for specific interfaces.
+
+
+#### Show commands
+
+* **show sflow**
+ * Displays the current configuration, global defaults as well as user configured values including collectors.
+* **show sflow interface**
+ * Displays the current running configuration of sflow interfaces.
+
+#### Example SONiC CLI configuration ####
+
+# sflow collector add collector1 10.100.12.13
+
+# sflow collector add collector2 10.144.1.2 --port 6344 --vrf mgmt
+
+# sflow agent-id add loopback0
+
+# sflow enable
+
+# sflow sample-direction both
+
+# sflow interface disable Ethernet0
+
+# sflow interface sample-direction Ethernet0 tx
+
+# sflow interface sample-rate Ethernet16 32768
+
+The configDB objects for the above CLI is given below:
+
+```
+{
+ "SFLOW_COLLECTOR": {
+ "collector1": {
+ "collector_ip": "10.100.12.13",
+ "collector_port": "6343"
+ "collector_vrf": "default"
+ },
+ "collector2": {
+ "collector_ip": "10.144.1.2",
+ "collector_port": "6344"
+ "collector_vrf": "mgmt"
+ }
+ },
+
+ "SFLOW": {
+ "global": {
+ "admin_state": "up"
+ "polling_interval": "20"
+ "agent_id": "loopback0"
+ "sample_direction": "both"
+ }
+ }
+ "SFLOW_SESSION": {
+ "Ethernet0": {
+ "admin_state": "down"
+ "sample_rate": "40000"
+ "sample_direction": "tx"
+ }
+}
+```
+
+# show sflow
+
+Displays the current configuration, global defaults as well as user configured values including collectors.
+
+```
+sFlow Global Information:
+ sFlow Admin State: up
+ sFlow Sample Direction: both
+ sFlow Polling Interval: 0
+ sFlow AgentID: default
+
+ 2 Collectors configured:
+ Name: prod IP addr: fe80::6e82:6aff:fe1e:cd8e UDP port: 6343 VRF: mgmt
+ Name: ser5 IP addr: 172.21.35.15 UDP port: 6343 VRF: default
+
+
+```
+
+# show sflow interface
+
+Displays the current running configuration of sflow interfaces.
+```
+Interface Admin Status Sampling rate Sampling direction
+--------- ------------ ------------- -------------------
+Ethernet0 down 40000 rx
+Ethernet1 up 25000 tx
+Ethernet2 up 40000 both
+Ethernet3 up 40000 both
+Ethernet4 up 40000 rx
+Ethernet5 up 40000 rx
+
+```
+
+### 6.6 **DB and Schema changes**
+
+#### ConfigDB Table & Schema
+
+A new SFLOW_COLLECTOR ConfigDB table entry would be added.
+```
+SFLOW_COLLECTOR|{{collector_name}}
+ "collector_ip": {{ip_address}}
+ "collector_port": {{ uint32 }} (OPTIONAL)
+ "collector_vrf": {{string}}
+
+; Defines schema for sFlow collector configuration attributes
+key = SFLOW_COLLECTOR:collector_name ; sFlow collector configuration
+; field = value
+COLLECTOR_IP = IPv4address / IPv6address ; Ipv4 or IpV6 collector address
+COLLECTOR_PORT = 1*5DIGIT ; destination L4 port : a number between 0 and 65535
+COLLECTOR_VRF = "default" | "mgmt" ; the VRF for the collector, currently only 'default' and 'mgmt' is supported
+
+;value annotations
+collector_name = 1*16VCHAR
+```
+
+A new SFLOW table will be added which holds global configurations
+```
+; Defines schema for SFLOW table which holds global configurations
+key = SFLOW
+ADMIN_STATE = "up" / "down"
+POLLING_INTERVAL = 1*3DIGIT ; counter polling interval
+AGENT_ID = ifname ; Interface name
+SAMPLE_DIRECTION = "rx"/"tx"/"both" ; Sampling direction
+```
+
+A new SFLOW_SESSION table would be added.
+```
+key SFLOW_SESSION:interface_name
+ADMIN_STATE = "up" / "down"
+SAMPLE_RATE = 1*7DIGIT ; average number of packets skipped before the sample is taken
+SAMPLE_DIRECTION = "rx"/"tx"/"both" ; Sampling direction
+
+```
+
+#### AppDB & Schema
+
+A new SFLOW_SESSION_TABLE is added to the AppDB:
+
+```
+; Defines schema for SFLOW_SESSION_TABLE which holds global configurations
+key = SFLOW_SESSION_TABLE:interface_name
+ADMIN_STATE = "up" / "down"
+SAMPLE_RATE = 1*7DIGIT ; average number of packets skipped before the sample is taken
+SAMPLE_DIRECTION = "rx"/"tx"/"both" ; Sampling direction
+```
+
+A new SFLOW_SAMPLE_RATE_TABLE table which maps interface speed to the sample rate for that speed is added to the AppDB
+```
+; Defines schema for SFLOW_SAMPLE_RATE which maps interface speed to sampling rate
+key = SFLOW_SAMPLE_RATE_TABLE:speed
+SAMPLE_RATE = 1*7DIGIT ; average number of packets skipped before the sample is taken
+```
+Where speed = 1*6DIGIT ; port line speed in Mbps
+
+#### StateDB Schema
+Add "PORT_EGRESS_SAMPLE_CAPABLE" under switch capability.
+
+```
+"SWITCH_CAPABILITY|switch": {
+ "value": {
+ "PORT_EGRESS_SAMPLE_CAPABLE": "true"
+ }
+ }
+```
+#### **DB Migration**
+Since there is a change in schema for SFLOW and SFLOW_SESSION in config DB and SFLOW_SESSION_TABLE in APP DB, we will add support to migrate the entries to new schema in db_migrator.py. Default behavior would be append the existing entries with "sample_direction" with value "rx".
+
+
+Existing ConfigDB schema
+```
+"SFLOW": {
+ "global": {
+ "admin_state": "up",
+ "polling_interval": "20",
+ "agent_id": "loopback0"
+ }
+ }
+"SFLOW_SESSION": {
+ "Ethernet0": {
+ "admin_state": "down",
+ "sample_rate": "40000"
+ },
+}
+```
+After migration
+```
+"SFLOW": {
+ "global": {
+ "admin_state": "up",
+ "polling_interval": "20",
+ "agent_id": "loopback0",
+ "sample_direction": "rx"
+ }
+ }
+"SFLOW_SESSION": {
+ "Ethernet0": {
+ "admin_state": "down",
+ "sample_rate": "40000",
+ "sample_direction": "rx"
+ }
+}
+```
+**APP DB Migration**
+
+First-time when user migrates from non-supported to supported version.
+
+Before upgrade:
+```
+ "SFLOW_TABLE:global": {
+ "admin_state": "up"
+ },
+ "SFLOW_SESSION_TABLE:Ethernet6": {
+ "admin_state": "up",
+ "sample_rate": "1000"
+ }
+
+```
+Post upgrade:
+```
+"SFLOW_TABLE:global": {
+ "admin_state": "up",
+ "sample_direction": "rx"
+ },
+ "SFLOW_SESSION_TABLE:Ethernet6": {
+ "admin_state": "up",
+ "sample_rate": "1000",
+ "sample_direction": "rx"
+ }
+
+```
+
+### 6.7 **sflow container**
+
+hsflowd (https://github.com/sflow/host-sflow) is the most popular open source implementation of the sFlow agent and provides support for DNS-SD (http://www.dns-sd.org/) and can be dockerised. hsflowd supports sFlow version 5 (https://sflow.org/sflow_version_5.txt which supersedes RFC 3176). hsflowd will run as a systemd service within the sflow docker.
+
+CLI configurations will be saved to the ConfigDB. Once the genetlink channel has been initialised and the sFlow traps mapped to the genetlink group, the hsflowd service is started. The service startup script will derive the /etc/hsflowd.conf from the ConfigDB. Config changes will necessitate restart of hsflowd. hsflowd provides the necessary statistics for the "show" commands. CLI "config" commands will retrieve the entries in the config DB.
+
+#### sflowmgrd
+
+The sflowmgrd consumes sflow config DB changes and updates the SFLOW APP DB tables.
+
+The sflowmgrd daemon listens to SFLOW_COLLECTOR to construct the hsflowd.conf and start the hsflowd service.
+The mapping between the SONiC sflow CLI parameters and the host-sflow is given below:
+
+SONIC CLI parameter| hsflowd.conf equivalent
+-------------------|------------------------
+collector ip-address | collector.ip
+collector port| collector.UDPPort
+collecttor vrf| collector.vrf
+agent ip-address | agentIP
+max-datagram-size | datagramBytes
+sample-rate | sampling
+
+The master list of supported host-sflow tokens are found in host-sflow/src/Linux/hsflowtokens.h
+
+sflowmgrd also listens to SFLOW to propagate the sampling rate changes to App DB SFLOW_TABLE.
+
+#### hsflowd service
+
+hsflowd provides an module adaptation layer for interfacing with the NOS. In the host-sflow repo, a src/Linux/mod_sonic.c adaption layer will be provided for hsflowd APIs to SONiC that deal with hsflowd initialization, configuration changes, packet sample consumption etc. More specifically, SONiC will register and provide callbacks for the following HSP events:
+
+hsflowd bus/events|SONiC callback actions
+------------------|----------------------
+ pollBus/HSPEVENT_INTF_READ | select all switchports for sampling by default
+ pollBus/HSPEVENT_INTF_SPEED | set sampling rate
+ pollBus/HSPEVENT_UPDATE_NIO | poll interface state from STATE_DB:PORT_TABLE and update counter stats in SFLHost_nio_counters from COUNTER DB
+ pollBus/HSPEVENT_CONFIG_CHANGED)| Change sampling rate (/ port speed changed)
+ packetBus/HSPEVENT_CONFIG_CHANGED | open netlink socket and register HsflowdRx()
+
+Refer to host-sflow/src/Linux/hsflowd.h for a list of events.
+
+### 6.8 **SWSS and syncd changes**
+
+### sFlowOrch
+
+An sFlowOrch is introduced in the Orchagent to handle configuration requests. The sFlowOrch essentially facilitates the creation/deletion of samplepacket sessions as well as get/set of session specific attributes. sFlowOrch sets the genetlink host interface that is to be used by the SAI driver to deliver the samples.
+
+Also, it monitors the SFLOW_SESSIONS_TABLE and PORT state to determine sampling rate / speed changes to derive and set the sampling rate for all the interfaces. Ingress/Egress Sampling is enabled on the interfaces based on direction setting. It uses the SAI samplepacket APIs to set each ports's sampling rate.
+
+### Rate limiting
+
+Considering that sFlow backoff mechanism is not being implemented, users should consider rate limiting sFlow samples using the currently existing COPP mechanism (the COPP config (e.g. src/sonic-swss/swssconfig/sample/00-copp.config.json) can include appropriate settings for the samplepacket trap and initialised using swssconfig).
+
+### 6.9 **SAI changes**
+
+Creating sFlow sessions and setting attributes (e.g. sampling rate) is described in SAI proposal : https://github.com/opencomputeproject/SAI/tree/master/doc/Samplepacket
+
+As per the sFlow specification, each packet sample should have certain minimal meta data for processing by the sFlow analyser. The psample infrastructure (http://man7.org/linux/man-pages/man8/tc-sample.8.html) already describes the desired metadata fields (which the SAI driver needs to add to each sample):
+
+```
+SAMPLED PACKETS METADATA FIELDS
+ The metadata are delivered to userspace applications using the
+ psample generic netlink channel, where each sample includes the
+ following netlink attributes:
+
+ PSAMPLE_ATTR_IIFINDEX
+ The input interface index of the packet, if there is one.
+
+ PSAMPLE_ATTR_OIFINDEX
+ The output interface index of the packet. This field is not
+ relevant on ingress sampling
+
+ PSAMPLE_ATTR_ORIGSIZE
+ The size of the original packet (before truncation)
+
+ PSAMPLE_ATTR_SAMPLE_GROUP
+ The psample group the packet was sent to
+
+ PSAMPLE_ATTR_GROUP_SEQ
+ A sequence number of the sampled packet. This number is
+ incremented with each sampled packet of the current psample
+ group
+
+ PSAMPLE_ATTR_SAMPLE_RATE
+ The rate the packet was sampled with
+```
+
+The SAI driver may provide the interface OIDs corresponding to the IIFINDEX AND OIFINDEX. The hsflowd mod_sonic HsflowdRx() may have to map these correspondingly to the netdev ifindex. Note that the default PSAMPLE_ATTR_SAMPLE_GROUP that hsflowd expects is 1 for ingress and 2 for egress.
+
+Depending on platform capabilities, SAI driver may report additional attributes defined in https://github.com/torvalds/linux/blob/master/include/uapi/linux/psample.h. For example, PSAMPLE_ATTR_OUT_TC (egress queue), PSAMPLE_ATTR_OUT_TC_OCC (egress queue depth), and PSAMPLE_ATTR_LATENCY (transit delay) populate the sFlow Transit Delay Structures (https://sflow.org/sflow_transit.txt).
+
+Rather than define a new framework for describing the metadata for sFlow use, SAI would re-use the framework that the psample driver (https://github.com/torvalds/linux/blob/master/net/psample/psample.c) currently uses. The psample kernel driver is based on the Generic Netlink subsystem that is described in https://wiki.linuxfoundation.org/networking/generic_netlink_howto. SAI ASIC drivers supporting sFlow may choose to use the psample.ko driver as-is or may choose to implement the generic netlink interface (that complies with the above listed metadata) using a private generic netlink family.
+
+#### SAI Host Interface based on Generic Netlink
+
+During SWSS init (as part of copporch), based on the swssconfig/sample/00-copp.config.json settings, sai_create_hostif_fn() is used to let the SAI driver create a special genetlink interface (type SAI_HOST_INTERFACE_TYPE_GENETLINK) and associate it with generic netlink family (SAI_HOST_INTERFACE_ATTR_NAME) and multicast group name (SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME). Later, sai_create_hostif_table_entry_fn() is used to map SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET to the genetlink sai_host_if.
+
+syncd/SAI implementations can use one of the following methods to create the genetlink interface:
+
+1. As part of syncd/SAI driver init, a driver based on the standard psample driver (genetlink family ="psample" and multicast group "packets") may be installed which would create the genetlink. In this case the sai_create_hostif_fn() determines that the genetlink interface is already created and merely associates the sai_host_if to the genetlink.
+
+2. The genetlink interface may alternatively be created during the call to sai_create_hostif_fn().
+
+
+#### Changes in SAI to support the GENETLINK host interface
+
+The changes in SAI to support the GENETLINK host interface is highlighted below:
+
+```
+ /** Generic netlink */
+ SAI_HOSTIF_TYPE_GENETLINK
+
+ /**
+ * @brief Name [char[SAI_HOSTIF_NAME_SIZE]]
+ *
+ * The maximum number of characters for the name is SAI_HOSTIF_NAME_SIZE - 1 since
+ * it needs the terminating null byte ('\0') at the end.
+ *
+ * In case of GENETLINK, name refers to the genl family name
+ *
+ * @type char
+ * @flags MANDATORY_ON_CREATE | CREATE_ONLY
+ * @condition SAI_HOSTIF_ATTR_TYPE == SAI_HOSTIF_TYPE_NETDEV or SAI_HOSTIF_ATTR_TYPE == SAI_HOSTIF_TYPE_GENETLINK
+ */
+ SAI_HOSTIF_ATTR_NAME,
+
+ /**
+ * @brief Name [char[SAI_HOSTIF_GENETLINK_MCGRP_NAME_SIZE]]
+ *
+ * The maximum number of characters for the name is SAI_HOSTIF_GENETLINK_MCGRP_NAME_SIZE - 1
+ * Set the Generic netlink multicast group name on which the packets/buffers
+ * are received on this host interface
+ *
+ * @type char
+ * @flags MANDATORY_ON_CREATE | CREATE_ONLY
+ * @condition SAI_HOSTIF_ATTR_TYPE == SAI_HOSTIF_TYPE_GENETLINK
+ */
+ SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME,
+
+ /** Receive packets via Linux generic netlink interface */
+ SAI_HOSTIF_TABLE_ENTRY_CHANNEL_TYPE_GENETLINK
+```
+#### Creating a GENETLINK Host Interface
+
+Below is an example code snip that shows how a GENETLINK based host interface is created. It is assumed that the application has already installed the psample.ko and created multicast group 100.
+
+```
+// Create a Host Interface based on generic netlink
+sai_object_id_t host_if_id;
+sai_attribute_t sai_host_if_attr[3];
+
+sai_host_if_attr[0].id=SAI_HOST_INTERFACE_ATTR_TYPE;
+sai_host_if_attr[0].value=SAI_HOST_INTERFACE_TYPE_GENETLINK;
+
+sai_host_if_attr[1].id= SAI_HOST_INTERFACE_ATTR_NAME;
+sai_host_if_attr[1].value="psample";
+
+sai_host_if_attr[2].id= SAI_HOSTIF_ATTR_GENETLINK_MCGRP_NAME;
+sai_host_if_attr[2].value="packets";
+
+sai_create_host_interface_fn(&host_if_id, 9, sai_host_if_attr);
+```
+
+### Mapping a sFlow (SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET) trap to a GENETLINK host interface multicast group id
+
+Below is the code snip that outlines how an sFlow trap is mapped to the GENETLINK host interface created in the previous section.
+
+```
+// Configure the host table to receive traps on the generic netlink socket
+
+sai_object_id_t host_table_entry;
+sai_attribute_t sai_host_table_attr[9];
+
+sai_host_table_attr[0].id=SAI_HOSTIF_TABLE_ENTRY_ATTR_TYPE;
+sai_host_table_attr[0].value= SAI_HOST_INTERFACE_TABLE_ENTRY_TYPE_TRAP_ID;
+
+sai_host_table_attr[1].id= SAI_HOSTIF_TABLE_ENTRY_ATTR_TRAP_ID;
+sai_host_table_attr[1].value=sflow_trap_id; // Object referencing SAMPLEPACKET trap
+
+sai_host_table_attr[2].id= SAI_HOSTIF_TABLE_ENTRY_ATTR_CHANNEL;
+sai_host_table_attr[2].value= SAI_HOSTIF_TABLE_ENTRY_CHANNEL_TYPE_GENETLINK;
+
+sai_host_table_attr[3].id= SAI_HOSTIF_TABLE_ENTRY_ATTR_HOST_IF;
+sai_host_table_attr[3].value=host_if_id; // host interface of type file descriptor for GENETLINK
+
+sai_create_hostif_table_entry_fn(&host_table_entry, 4, sai_host_table_attr);
+```
+
+It is assumed that the trap group and the trap itself have been defined using sai_create_hostif_trap_group_fn() and sai_create_hostif_trap_fn().
+
+#### SAI capability query for Sflow
+```
+ sai_attr_capability_t capability;
+// Ingress Sflow capability query
+status = sai_query_attribute_capability(gSwitchId, SAI_OBJECT_TYPE_PORT, SAI_PORT_ATTR_INGRESS_SAMPLEPACKET_ENABLE, &capability);
+
+// Egress Sflow capability query
+status = sai_query_attribute_capability(gSwitchId, SAI_OBJECT_TYPE_PORT, SAI_PORT_ATTR_EGRESS_SAMPLEPACKET_ENABLE, &capability);
+```
+#### Mapping of Sflow to interface
+```
+// Ingress Sflow mapped to "ingress-sample" rate.
+attr.id = SAI_PORT_ATTR_INGRESS_SAMPLEPACKET_ENABLE;
+attr.value.oid = sample_id;
+set_port_attribute(port_id, &attr);
+
+// Egress Sflow mapped to direction "egress-sample" rate.
+attr.id = SAI_PORT_ATTR_EGRESS_SAMPLEPACKET_ENABLE;
+attr.value.oid = sample_id;
+set_port_attribute(port_id, &attr);
+
+```
+## 7 **CLI Yang Model**
+```
+diff --git a/src/sonic-yang-models/yang-models/sonic-sflow.yang b/src/sonic-yang-models/yang-models/sonic-sflow.yang
+index 62984f064..601d112fd 100644
+--- a/src/sonic-yang-models/yang-models/sonic-sflow.yang
++++ b/src/sonic-yang-models/yang-models/sonic-sflow.yang
+@@ -28,10 +28,28 @@ module sonic-sflow{
+
+ description "SFLOW yang Module for SONiC OS";
+
++ revision 2023-03-14 {
++ description "Add direction command to support egress sflow";
++ }
++
+ revision 2021-04-26 {
+ description "First Revision";
+ }
+
++ typedef sample_direction {
++ type enumeration {
++ enum rx {
++ description "rx direction";
++ }
++ enum tx {
++ description "tx direction";
++ }
++ enum both {
++ description "Both tx and rx direction";
++ }
++ }
++ }
++
+ container sonic-sflow {
+
+ container SFLOW_COLLECTOR {
+@@ -89,6 +107,13 @@ module sonic-sflow{
+ }
+ description "Sets the packet sampling rate. The rate is expressed as an integer N, where the intended sampling rate is 1/N packets.";
+ }
++
++ leaf sample_direction {
++ type sample_direction;
++ default "rx";
++ description "sflow sample direction"
++ }
++
+ } /* end of list SFLOW_SESSION_LIST */
+ } /* end of container SFLOW_SESSION */
+
+@@ -133,6 +158,13 @@ module sonic-sflow{
+ }
+ description "Interface name";
+ }
++
++ leaf sample_direction {
++ type sample_direction;
++ default "rx";
++ description "sflow sample direction"
++ }
++
+ } /* end of container global */
+ } /* end of container SFLOW */
+
+```
+## 8 **Warmboot support**
+
+sFlow packet/counter sampling should not be affected after a warm reboot. In case of a planned warm reboot, packet sampling will be stopped.
+
+## 9 **sFlow in Virtual Switch**
+
+On the SONiC VS, SAI calls would map to the tc_sample commands on the switchport interfaces (http://man7.org/linux/man-pages/man8/tc-sample.8.html).
+
+## 10 **Build**
+
+* The host-sflow package will be built with the mod_sonic callback implementations using the FEATURES="SONIC" option
+
+## 11 **Restrictions**
+* /etc/hsflowd.conf should not be modified manually. While it should be possible to change /etc/hsflowd.conf manually and restart the sflow container, it is not recommended.
+* configuration updates will necessitate hsflowd service restart
+* hsflowd daemon will initialize only after receiving the SYSTEM_READY|SYSTEM_STATE Status=Up from SONiC. The system ready state however depends on all the monitored daemons to be ready. Failure on any of these, will result in system state to be down. In such scenarios, sflow will wait until 180 seconds and if system ready is not up will proceed with initialization. For system ready feature please visit https://github.com/sonic-net/SONiC/blob/master/doc/system_health_monitoring/system-ready-HLD.md
+
+## 12 **Unit Test cases**
+Unit test case one-liners are given below:
+
+| S.No | Test case synopsis |
+|------|-----------------------------------------------------------------------------------------------------------------------------------------|
+| 1 | Verify that the SFLOW_COLLECTOR configuration additions from CONFIG_DB are processed by hsflowd. |
+| 2 | Verify that the SFLOW_COLLECTOR configuration deletions from CONFIG_DB are processed by hsflowd. |
+| 3 | Verify that sFlowOrch creates "psample" multicast group "packets" if there is not psample driver inserted. |
+| 4 | Verify that sFlowOrch maps SAI_HOSTIF_TRAP_TYPE_SAMPLEPACKET trap to the "psample" family and multicast group "packets". |
+| 5 | Verify that it is possible to enable and disable sflow using the SFLOW table's admin_state field in CONFIG_DB |
+| 6 | Verify that interfaces can be enabled/disabled using additions/deletions in SFLOW_SESSION table. |
+| 7 | Verify that it is possible to change the counter polling interval using the SFLOW table in CONFIG_DB |
+| 8 | Verify that it is possible to change the agent-id using the SFLOW table in CONFIG_DB
+| 9 | Verify that it is possible to change the sampling rate per interface using SFLOW_SESSION interface sample_rate field for direction tx, rx and both in CONFIG_DB |
+| 10 | Verify that changes to SFLOW_SESSION CONFIG_DB entry is pushed to the corresponding table in APP_DB and to ASIC_DB by sFlowOrch |
+| 11 | Verify that collector and per-interface changes get reflected using the "show sflow" and "show sflow interface" commands |
+| 12 | Verify that packet samples are coming into hsflowd agent as per the global and per-interface configuration |
+| 13 | Verify that the hsflowd generated UDP datagrams are generated as expected and contain all the PSAMPLE_ATTR* attributes in the meta data |
+| 14 | Verify that samples are received when either 1 or 2 collectors are configured. |
+| 15 | Verify the sample collection for both IPv4 and IPv6 collectors. |
+| 16 | Verify that sample collection works on all ports or on a subset of ports (using lowest possible sampling rate). |
+| 17 | Verify that counter samples are updated every 20 seconds |
+| 18 | Verify that packet & counter samples stop for a disabled interface. |
+| 19 | Verify that sampling changes based on interface speed and per-interface and direction sampling rate change. Validate for sample-direction rx,txand both. |
+| 20 | Verify that if sFlow is not enabled in the build, the sflow docker is not started |
+| 21 | Verify that sFlow docker can be stopped and restarted and check that packet and counter sampling restarts. |
+| 22 | Verify that with config saved in the config_db.json, restarting the unit should result in sFlow coming up with saved configuration. |
+| 23 | Verify sFlow functionality with valid startup configuration and after a normal reboot, fast-boot and warm-boot. |
+| 24 | Verify that the sFlow hsflowd logs are emitted to the syslog file for various severities. |
+| 25 | Verify that the swss restart works without issues when sflow is enabled and continues to sample as configured. |
+| 26 | Verify that collector functions properly on 'default' VRF and can send counter and flow samples |
+| 27 | Verify that collector functions properly on 'mgmt' VRF and can send counter and flow samples |
+| 28 | Verify that egress sampling is applied based on query-capability. |
+|29 | Verify CONFIG DB migration changes for SFLOW SESSION table for old to new schema
+|30 | Verify APP DB migration changes for SFLOW SESSION table for old to new schema
+
+## 13 **System Testcase**
+New ptf test cases will be added for this feature.
+
+## 14 **Action items**
+* Determine if it is possible to change configuration without restarting hsflowd
+* Check host-sflow licensing options
+* Change hsflowd to version 2.0.45-1 for accepting egress samples.
diff --git a/doc/sfp-cmis/CMIS-custom-SI-settings.md b/doc/sfp-cmis/CMIS-custom-SI-settings.md
index e2bdb1a9043..f6fe8b666ff 100644
--- a/doc/sfp-cmis/CMIS-custom-SI-settings.md
+++ b/doc/sfp-cmis/CMIS-custom-SI-settings.md
@@ -48,7 +48,7 @@
| SI | Signal Integrity |
| EC | Explicit Control |
| TX | Transmit |
-| RX | Recieve |
+| RX | Receive |
| EQ | Equalizer |
### References
@@ -63,7 +63,7 @@
This is a high-level design document describing the way to apply custom SI settings for CMIS supported modules.
## 1 Introduction and Scope
-Certain high-speed QSFP_DD, OSFP and QSFP modules require Signal Integrity (SI) settings to match platform media settings in order to achieve link stability, right tunning and optimal performance.
+Certain high-speed QSFP_DD, OSFP and QSFP modules require Signal Integrity (SI) settings to match platform media settings in order to achieve link stability, right tuning and optimal performance.
### 1.1 Clause from CMIS5p0 spec for Signal Integrity
Excerpt from CMIS5.0 spec providing definition of Signal Integrity:
@@ -86,7 +86,7 @@ This feature would be enabled per platform basis. If platform wants to use this
## 3 Architecture Design
The SI media setting file optics_si_setting.json needs to be defined by each platform_vendor that will need SI settings. All SKUs of the platform will share the same optics_si_setting.json file. If no file is found, then this mechanism will be ignored.
-This file will have two blocks: the first is global level setting and the next is port level setting. These blocks will contain subblocks of range or indiviual ports. Inside this port block, there will be subblocks for different lane speeds which will eventuall have per-lane SI parameter setting values based on the type of vendor that are expected to be programmed. The SI settings will not depend on cable length.
+This file will have two blocks: the first is global level setting and the next is port level setting. These blocks will contain subblocks of range or individual ports. Inside this port block, there will be subblocks for different lane speeds which will eventually have per-lane SI parameter setting values based on the type of vendor that are expected to be programmed. The SI settings will not depend on cable length.
### 3.1 TX_SETTING:
TX EQ (TX input equalizer control) setting can be FIXED or ADAPTIVE. Only adaptive EQ should be used for TX input, and it's enabled as the default setting in module. Fixed EQ is not recommended for TX direction and will not work until the SI/Hardware team explicitly recommends it.
@@ -264,7 +264,7 @@ There are no changes to SAI API
There are no changes to any CLI/YANG model or Config DB enhancements.
## 7 Warmboot and Fastboot Design Impact
-There is no impact to Warmboot and Fastboot design. This feature is invoked as part of exisiting CMIS manager flow only
+There is no impact to Warmboot and Fastboot design. This feature is invoked as part of existing CMIS manager flow only
## 8 Restrictions or Limitations
If transceiver is not present:
@@ -272,6 +272,6 @@ If transceiver is not present:
Modules that do not support CMIS and not part of CMIS state machine are not in the scope of this document.
## 9 Unit Test cases
-1. Check XCVRD/CMIS log if optics SI settings are succesfully applied for module which expect the SI settings.
+1. Check XCVRD/CMIS log if optics SI settings are successfully applied for module which expect the SI settings.
2. Check XCVRD/CMIS log if optics SI settings are ignored for modules that dont expect the SI settings.
3. Validate no link flaps or link down once SI settings are applied
diff --git a/doc/sfp-cmis/Interface-Link-bring-up-sequence.md b/doc/sfp-cmis/Interface-Link-bring-up-sequence.md
index 351fcb8dc50..0baeebcf816 100644
--- a/doc/sfp-cmis/Interface-Link-bring-up-sequence.md
+++ b/doc/sfp-cmis/Interface-Link-bring-up-sequence.md
@@ -39,7 +39,7 @@ Deterministic Approach for Interface Link bring-up sequence
# About this Manual
-This is a high-level design document describing the need to have determinstic approach for
+This is a high-level design document describing the need to have deterministic approach for
Interface link bring-up sequence and workflows for use-cases around it
# Abbreviation
@@ -109,7 +109,7 @@ Interface link bring-up sequence and workflows for use-cases around it
# Objective
-Have a determistic approach for Interface link bring-up sequence for all interfaces types i.e. below sequence to be followed:
+Have a deterministic approach for Interface link bring-up sequence for all interfaces types i.e. below sequence to be followed:
1. Initialize and enable NPU Tx and Rx path
2. For system with 'External' PHY: Initialize and enable PHY Tx and Rx on both line and host sides; ensure host side link is up
3. Then only perform optics data path initialization/activation/Tx enable (for CMIS complaint optical modules) and Tx enable (for SFF complaint optical modules)
@@ -127,7 +127,7 @@ Plan is to follow this high-level work-flow sequence to accomplish the Objective
- deterministic approach to bring the interface will eliminate any link stability issue which will be difficult to chase in the production network
e.g. If there is a PHY device in between, and this 'deterministic approach' is not followed, PHY may adapt to a bad signal or interface flaps may occur when the optics tx/rx enabled during PHY initialization.
- there is a possibility of interface link flaps with non-quiescent optical modules if this 'deterministic approach' is not followed
- - It helps bring down the optical module laser when interface is adminstiratively shutdown. Per the workflow here, this is acheived by xcvrd listening to host_tx_ready field from PORT_TABLE of STATE_DB. Turning the laser off would reduce the power consumption and avoid any lab hazard
+ - It helps bring down the optical module laser when interface is adminstiratively shutdown. Per the workflow here, this is achieved by xcvrd listening to host_tx_ready field from PORT_TABLE of STATE_DB. Turning the laser off would reduce the power consumption and avoid any lab hazard
- Additionally provides uniform workflow (from SONiC NOS) across all interface types with or without module presence.
- This synchronization will also benefit SFP+ optical modules as they are "plug N play" and may not have quiescent functionality. (xcvrd can use the optional 'soft tx disable' ctrl reg to disable the tx)
@@ -162,7 +162,7 @@ Please refer to the flow/sequence diagrams which covers the following required
Else, if ‘skip_xcvrd_cmis_mgr’ is set/found 'true' by xcvrd, it would skip launching CMIS task manager and this feature would remain disabled.
If a platform/vendor does not specify/set ‘skip_xcvrd_cmis_mgr’, xcvrd would exercise the default workflow (i.e. when xcvrd detects QSFP-DD, it would luanch CMIS task manager and initialize the module per CMIS specification).
-Note: This feature flag (skip_xcvrd_cmis_mgr) was added as a flexibility in case vendor/platform intend to disable this feature and not use CMIS task manager. However, techinically, as mentioned in this document, that should not be the case.
+Note: This feature flag (skip_xcvrd_cmis_mgr) was added as a flexibility in case vendor/platform intend to disable this feature and not use CMIS task manager. However, technically, as mentioned in this document, that should not be the case.
Workflow :
@@ -185,7 +185,7 @@ Note: This feature flag (skip_xcvrd_cmis_mgr) was added as a flexibility in case
# No transceiver present
if transceiver is not present:
- - All the workflows mentioned above will reamin same ( or get exercised) till host_tx_ready field update
+ - All the workflows mentioned above will remain same ( or get exercised) till host_tx_ready field update
- xcvrd will not perform any action on receiving host_tx_ready field update
# Port re-initialization during syncd/swss/orchagent crash
diff --git a/doc/sfp-cmis/cmis-init.md b/doc/sfp-cmis/cmis-init.md
index 810d55969e9..634aaba1721 100644
--- a/doc/sfp-cmis/cmis-init.md
+++ b/doc/sfp-cmis/cmis-init.md
@@ -147,7 +147,7 @@ Functionality should continue to work across warm boot.
# Functional Description
-- The **pmon#xcvrd** should detect the module type of the attched CMIS transceiver and
+- The **pmon#xcvrd** should detect the module type of the attached CMIS transceiver and
post its module information onto the **STATE_DB**
- When a CMIS transceiver is attached, the **show interfaces transceiver eeprom**
should display the advertised applications of the transceiver.
@@ -239,7 +239,7 @@ to support multiple CMIS transceivers in one single thread.
- Prior to advancing the state, CmisManagerTask should always double-check the hardware module and datapath states.
- Prior to handling the CMIS state transitions, the following checkers are always performed
- **Check for the transceiver presence** via sfp.get_presence(),
- abort the initialization sequence if it's no loner present
+ abort the initialization sequence if it's no longer present
- **Validate the transceiver module type** via sfp.get_transceiver_info()['type_abbrv_name'],
abort the initialization sequence if it's not a QSFP-DD
- **Validate the transceiver memory type** via sfp.get_transceiver_info()['memory_type'],
@@ -344,7 +344,7 @@ Add the following stub routines
## sonic-utilities/sfputil
-- Add supprot to show the CMIS application advertisement
+- Add support to show the CMIS application advertisement
## CLI commands
diff --git a/doc/sfp-refactor/sfp-refactor.md b/doc/sfp-refactor/sfp-refactor.md
index c6dbce9b6f5..f99ae18304c 100644
--- a/doc/sfp-refactor/sfp-refactor.md
+++ b/doc/sfp-refactor/sfp-refactor.md
@@ -125,7 +125,7 @@ This document summarizes an approach to refactor the Sfp-related functionality i
The current platform API model is such that base classes in sonic-platform-common define a common, PI interface that can be implemented in PD classes.
-For Sfp, there is a great deal of PI logic that exists in sonic_sfp pertaining to different xcvr specs. Ideally, platform vendors reponsible for implementing the PD classes would only need to add logic that is actually PD.
+For Sfp, there is a great deal of PI logic that exists in sonic_sfp pertaining to different xcvr specs. Ideally, platform vendors responsible for implementing the PD classes would only need to add logic that is actually PD.
However, the reality today is that some parts of the Sfp platform API are PI whereas some parts are PD, and platform vendors are required to take care of both in their SfpBase-derived implementations. The problem is that sonic_sfp (much of it being legacy code from the older platform API model) has not been updated to handle the requirements of the newer Sfp platform API, and vendors are having to fill in implementation gaps for themselves. This is resulting in a lot of duplicate work being done for things that should be common across platforms.
@@ -151,7 +151,7 @@ With these abstractions, the most that should be exposed to any clients using th
The correct specification abstraction needs to be selected at runtime to interpret a xcvr’s memory map correctly. This should be done by reading the first byte in the xcvr’s EEPROM, which contains an identifier value whose meaning is specified in Table 4-1 of SFF-8024. There should then be a set of mappings between identifier values and the specifications we support.
-This approach is in contrast to what's currenly done with selecting parsers based on the xcvr's port number, which can sometimes lead to the wrong memory map interpretation.
+This approach is in contrast to what's currently done with selecting parsers based on the xcvr's port number, which can sometimes lead to the wrong memory map interpretation.
### Vendor Specific Data
@@ -460,8 +460,8 @@ class XcvrApiFactory(object):
```
-* Mapping organized at top level according to identifers (0x00-0xFF)
-* Each identifer maps to 1 or more set of dotted paths to Python classes that are subclasses of XcvrApi, XcvrCodes, and XcvrMemMap.
+* Mapping organized at top level according to identifiers (0x00-0xFF)
+* Each identifier maps to 1 or more set of dotted paths to Python classes that are subclasses of XcvrApi, XcvrCodes, and XcvrMemMap.
* Identifiers in SFF-8024 included in this mapping must have a "public" key, providing classes corresponding to a public spec (e.g. SFF-8436)
* Vendors providing custom classes under a particular identifier do so under key corresponding to vendor's name (must match name read from EEPROM)
* Mappings under vendor name are further split according to model/part number
diff --git a/doc/sfputil/dump_sfp_eeprom.md b/doc/sfputil/dump_sfp_eeprom.md
index 3e87a954f74..5718415543b 100644
--- a/doc/sfputil/dump_sfp_eeprom.md
+++ b/doc/sfputil/dump_sfp_eeprom.md
@@ -49,7 +49,7 @@ Existing subcommand `eeprom-hexdump` shall be extended to dump eeprom data for a
1. `sfputil show eeprom-hexdump --port --page `: dump given page for given port
2. `sfputil show eeprom-hexdump --port `: dump page 0 for given port (to keep backwardcompatible)
-3. `sfputil show eeprom-hexdump --page `: dump given page for all ports, validate that page must be in range [0,255]. User is repsonsible for making sure the page existence.
+3. `sfputil show eeprom-hexdump --page `: dump given page for all ports, validate that page must be in range [0,255]. User is responsible for making sure the page existence.
4. `sfputil show eeprom-hexdump`: dump available pages for all ports. Available pages for different cable types are described below.
`sfputil show eeprom-hexdump` shall dump pages based on cable type:
diff --git a/doc/sfputil/read_write_eeprom_by_page.md b/doc/sfputil/read_write_eeprom_by_page.md
index 6be1ae20b7d..447fc8af098 100644
--- a/doc/sfputil/read_write_eeprom_by_page.md
+++ b/doc/sfputil/read_write_eeprom_by_page.md
@@ -1,199 +1,199 @@
-# sfputil | add the ability to read/write any byte from EERPOM both by page and offset #
-
-## Table of Content
-
-### Revision
-
-### Scope
-
-This document describes SONiC feature to read/write cable EEPROM data via SONiC CLI.
-
-### Definitions/Abbreviations
-
-N/A
-
-### Overview
-
-CLI sfputil shall be extended to support reading/writing cable EEPROM by page and offset. This implementation is based on existing platform API `sfp.read_eeprom` and `sfp.write_eeprom`.
-
-### Requirements
-
-- Support reading/writing cable EEPROM data by page, offset and size. For sff8472, wire address "a0h" or "a2h" must be provided by user.
-- Support basic validation for input parameter such as page, offset and size.
-- Support reading/writing cable EEPROM for all types of cables except RJ45.
-- User shall provide page and offset according to the standard. For example, CMIS page 1h starting offset is 128, offset less than 128 shall be treated as invalid.
-- Vendor who does not support `sfp.read_eeprom` and `sfp.write_eeprom` is expected to raise `NotImplementedError`, this error shall be properly handled
-- Others error shall be treated as read/write failure
-
-
-### Architecture Design
-
-The current architecture is not changed.
-
-### High-Level Design
-
-Submodule sonic-utilities shall be extended to support this feature.
-
-#### sonic-utilities
-
-Two new CLIs shall be added to sfputil module:
-
-- sfputil read-eeprom
-- sfputil write-eeprom
-
-For detail please check chapter [CLI/YANG model Enhancements](#cliyang-model-enhancements)
-
-The existing API `sfp.read_eeprom` and `sfp.write_eeprom` accept "overall offset" as parameter. They have no concept of page. If user wants to use it, user has to convert page and offset to "overall offset" manually. Different cable types use different covert method according to the standard. So, it is not user friendly to provide such API directly to user. sonic-utilities shall provide the function to translate from page offset to overall offset.
-
-##### CMIS validation
-
-Passive cable:
-- Valid page: 0
-- Valid offset: 0-255
-
-Active cable:
-- Valid page: 0-255
-= Valid offset: page 0 (0-255), other (128-255)
-
-For active cable, there is no "perfect" page validation as it is too complicated. User is responsible to make sure the page existence according to cable user manual.
-
-Example:
-```
-sfputil read-eeprom -p Ethernet0 -n 0 -o 255 -s 1 # valid
-sfputil read-eeprom -p Ethernet0 -n 0 -o 255 -s 2 # invalid size, out of range, 255+2=257 is not a valid offset
-sfputil read-eeprom -p Ethernet0 -n 0 -o 256 -s 1 # invalid offset 256 for page 0, must be in range [0, 255]
-sfputil read-eeprom -p Ethernet0 -n 1 -o 0 -s 1 # invalid offset 0 for page 1, must be >=128
-```
-
-##### sff8436 and sff8636 validation
-
-Passive cable:
-- Valid page: 0
-- Valid offset: 0-255
-
-Active cable:
-- Valid page: 0-255
-- Valid offset: page 0 (0-255), other (128-255)
-
-For active cable, there is no "perfect" page validation as it is too complicated. User is responsible to make sure the page existence according to cable user manual.
-
-```
-sfputil write-eeprom -p Ethernet0 -n 0 -o 255 -d ff # valid
-sfputil write-eeprom -p Ethernet0 -n 0 -o 255 -d ff00 # invalid size, out of range, 255+2=257 is not a valid offset
-sfputil write-eeprom -p Ethernet0 -n 0 -o 256 -d ff # invalid offset 256 for page 0, must be in range [0, 255]
-sfputil write-eeprom -p Ethernet0 -n 1 -o 0 -d ff # invalid offset 0 for page 1, must be >=128
-```
-
-##### sff8472 validation
-
-Passive cable:
-- Valid wire address: [A0h] (case insensitive)
-- Valid offset: A0h (0-128)
-
-Active cable:
-- Valid wire address: [A0h, A2h] (case insensitive)
-- Valid offset: A0h (0-255), A2h (0-255)
-
-```
-sfputil read-eeprom -p Ethernet0 -n 0 -o 0 -s 1 --wire-addr a0h # valid
-sfputil read-eeprom -p Ethernet0 -n 0 -o 0 -s 2 --wire-addr A0h # invalid size, out of range, 255+2=257 is not a valid offset
-sfputil read-eeprom -p Ethernet0 -n 1 -o 0 -s 1 --wire-addr a2h # invalid offset 256 for page 0, must be in range [0, 255]
-sfputil read-eeprom -p Ethernet0 -n 1 -o 0 -s 1 --wire-addr a0h # invalid offset 0 for page 1, must be >=128
-```
-
-### SAI API
-
-N/A
-
-### Configuration and management
-
-#### Manifest (if the feature is an Application Extension)
-
-N/A
-
-#### CLI/YANG model Enhancements
-
-##### sfputil read-eeprom
-
-```
-admin@sonic:~$ sfputil read-eeprom --help
-Usage: sfputil read-eeprom [OPTIONS]
-
- Read SFP EEPROM data
-
-Options:
- -p, --port Logical port name [required]
- -n, --page EEPROM page number [required]
- -o, --offset EEPROM offset within the page [required]
- -s, --size Size of byte to be read [required]
- --no-format Display non formatted data
- --wire-addr TEXT Wire address of sff8472
- --help Show this message and exit.
-```
-
-Example:
-
-```
-sfputil read-eeprom -p Ethernet0 -n 0 -o 100 -s 2
- 00000064 4a 44 |..|
-
-sfputil read-eeprom -p Ethernet0 -n 0 -o 0 -s 32
- 00000000 11 08 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
- 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
-
-sfputil read-eeprom -p Ethernet0 -n 0 -o 100 -s 2 --no-format
-4a44
-```
-
-##### sfputil write-eeprom
-
-```
-admin@sonic:~$ sfputil write-eeprom --help
-Usage: sfputil write-eeprom [OPTIONS]
-
- Write SFP EEPROM data
-
-Options:
- -p, --port Logical port name [required]
- -n, --page EEPROM page number [required]
- -o, --offset EEPROM offset within the page [required]
- -d, --data Hex string EEPROM data [required]
- --wire-addr TEXT Wire address of sff8472
- --verify Verify the data by reading back
- --help Show this message and exit.
-```
-
-Example:
-
-```
-sfputil write-eeprom -p Ethernet0 -n 0 -o 100 -d 4a44
-
-sfputil write-eeprom -p Etherent0 -n 0 -o 100 -d 4a44 --verify
-Error: Write data failed! Write: 4a44, read: 0000.
-```
-
-#### Config DB Enhancements
-
-N/A
-
-### Warmboot and Fastboot Design Impact
-
-N/A
-
-### Memory Consumption
-
-No memory consumption is expected when the feature is disabled via compilation and no growing memory consumption while feature is disabled by configuration.
-
-### Restrictions/Limitations
-
-- Vendor should support plaform API `sfp.read_eeprom` and `sfp.write_eeprom` to support this feature.
-
-### Testing Requirements/Design
-
-#### Unit Test cases
-
-- sonic-utilities unit test shall be extended to cover new subcommands
-
-#### System Test cases
-
-### Open/Action items - if any
+# sfputil | add the ability to read/write any byte from EERPOM both by page and offset #
+
+## Table of Content
+
+### Revision
+
+### Scope
+
+This document describes SONiC feature to read/write cable EEPROM data via SONiC CLI.
+
+### Definitions/Abbreviations
+
+N/A
+
+### Overview
+
+CLI sfputil shall be extended to support reading/writing cable EEPROM by page and offset. This implementation is based on existing platform API `sfp.read_eeprom` and `sfp.write_eeprom`.
+
+### Requirements
+
+- Support reading/writing cable EEPROM data by page, offset and size. For sff8472, wire address "a0h" or "a2h" must be provided by user.
+- Support basic validation for input parameter such as page, offset and size.
+- Support reading/writing cable EEPROM for all types of cables except RJ45.
+- User shall provide page and offset according to the standard. For example, CMIS page 1h starting offset is 128, offset less than 128 shall be treated as invalid.
+- Vendor who does not support `sfp.read_eeprom` and `sfp.write_eeprom` is expected to raise `NotImplementedError`, this error shall be properly handled
+- Others error shall be treated as read/write failure
+
+
+### Architecture Design
+
+The current architecture is not changed.
+
+### High-Level Design
+
+Submodule sonic-utilities shall be extended to support this feature.
+
+#### sonic-utilities
+
+Two new CLIs shall be added to sfputil module:
+
+- sfputil read-eeprom
+- sfputil write-eeprom
+
+For detail please check chapter [CLI/YANG model Enhancements](#cliyang-model-enhancements)
+
+The existing API `sfp.read_eeprom` and `sfp.write_eeprom` accept "overall offset" as parameter. They have no concept of page. If user wants to use it, user has to convert page and offset to "overall offset" manually. Different cable types use different convert method according to the standard. So, it is not user friendly to provide such API directly to user. sonic-utilities shall provide the function to translate from page offset to overall offset.
+
+##### CMIS validation
+
+Passive cable:
+- Valid page: 0
+- Valid offset: 0-255
+
+Active cable:
+- Valid page: 0-255
+= Valid offset: page 0 (0-255), other (128-255)
+
+For active cable, there is no "perfect" page validation as it is too complicated. User is responsible to make sure the page existence according to cable user manual.
+
+Example:
+```
+sfputil read-eeprom -p Ethernet0 -n 0 -o 255 -s 1 # valid
+sfputil read-eeprom -p Ethernet0 -n 0 -o 255 -s 2 # invalid size, out of range, 255+2=257 is not a valid offset
+sfputil read-eeprom -p Ethernet0 -n 0 -o 256 -s 1 # invalid offset 256 for page 0, must be in range [0, 255]
+sfputil read-eeprom -p Ethernet0 -n 1 -o 0 -s 1 # invalid offset 0 for page 1, must be >=128
+```
+
+##### sff8436 and sff8636 validation
+
+Passive cable:
+- Valid page: 0
+- Valid offset: 0-255
+
+Active cable:
+- Valid page: 0-255
+- Valid offset: page 0 (0-255), other (128-255)
+
+For active cable, there is no "perfect" page validation as it is too complicated. User is responsible to make sure the page existence according to cable user manual.
+
+```
+sfputil write-eeprom -p Ethernet0 -n 0 -o 255 -d ff # valid
+sfputil write-eeprom -p Ethernet0 -n 0 -o 255 -d ff00 # invalid size, out of range, 255+2=257 is not a valid offset
+sfputil write-eeprom -p Ethernet0 -n 0 -o 256 -d ff # invalid offset 256 for page 0, must be in range [0, 255]
+sfputil write-eeprom -p Ethernet0 -n 1 -o 0 -d ff # invalid offset 0 for page 1, must be >=128
+```
+
+##### sff8472 validation
+
+Passive cable:
+- Valid wire address: [A0h] (case insensitive)
+- Valid offset: A0h (0-128)
+
+Active cable:
+- Valid wire address: [A0h, A2h] (case insensitive)
+- Valid offset: A0h (0-255), A2h (0-255)
+
+```
+sfputil read-eeprom -p Ethernet0 -n 0 -o 0 -s 1 --wire-addr a0h # valid
+sfputil read-eeprom -p Ethernet0 -n 0 -o 0 -s 2 --wire-addr A0h # invalid size, out of range, 255+2=257 is not a valid offset
+sfputil read-eeprom -p Ethernet0 -n 1 -o 0 -s 1 --wire-addr a2h # invalid offset 256 for page 0, must be in range [0, 255]
+sfputil read-eeprom -p Ethernet0 -n 1 -o 0 -s 1 --wire-addr a0h # invalid offset 0 for page 1, must be >=128
+```
+
+### SAI API
+
+N/A
+
+### Configuration and management
+
+#### Manifest (if the feature is an Application Extension)
+
+N/A
+
+#### CLI/YANG model Enhancements
+
+##### sfputil read-eeprom
+
+```
+admin@sonic:~$ sfputil read-eeprom --help
+Usage: sfputil read-eeprom [OPTIONS]
+
+ Read SFP EEPROM data
+
+Options:
+ -p, --port Logical port name [required]
+ -n, --page EEPROM page number [required]
+ -o, --offset EEPROM offset within the page [required]
+ -s, --size Size of byte to be read [required]
+ --no-format Display non formatted data
+ --wire-addr TEXT Wire address of sff8472
+ --help Show this message and exit.
+```
+
+Example:
+
+```
+sfputil read-eeprom -p Ethernet0 -n 0 -o 100 -s 2
+ 00000064 4a 44 |..|
+
+sfputil read-eeprom -p Ethernet0 -n 0 -o 0 -s 32
+ 00000000 11 08 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+ 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+
+sfputil read-eeprom -p Ethernet0 -n 0 -o 100 -s 2 --no-format
+4a44
+```
+
+##### sfputil write-eeprom
+
+```
+admin@sonic:~$ sfputil write-eeprom --help
+Usage: sfputil write-eeprom [OPTIONS]
+
+ Write SFP EEPROM data
+
+Options:
+ -p, --port Logical port name [required]
+ -n, --page EEPROM page number [required]
+ -o, --offset EEPROM offset within the page [required]
+ -d, --data Hex string EEPROM data [required]
+ --wire-addr TEXT Wire address of sff8472
+ --verify Verify the data by reading back
+ --help Show this message and exit.
+```
+
+Example:
+
+```
+sfputil write-eeprom -p Ethernet0 -n 0 -o 100 -d 4a44
+
+sfputil write-eeprom -p Etherent0 -n 0 -o 100 -d 4a44 --verify
+Error: Write data failed! Write: 4a44, read: 0000.
+```
+
+#### Config DB Enhancements
+
+N/A
+
+### Warmboot and Fastboot Design Impact
+
+N/A
+
+### Memory Consumption
+
+No memory consumption is expected when the feature is disabled via compilation and no growing memory consumption while feature is disabled by configuration.
+
+### Restrictions/Limitations
+
+- Vendor should support platform API `sfp.read_eeprom` and `sfp.write_eeprom` to support this feature.
+
+### Testing Requirements/Design
+
+#### Unit Test cases
+
+- sonic-utilities unit test shall be extended to cover new subcommands
+
+#### System Test cases
+
+### Open/Action items - if any
diff --git a/doc/smart-switch/BFD/SmartSwitchDpuLivenessUsingBfd.md b/doc/smart-switch/BFD/SmartSwitchDpuLivenessUsingBfd.md
index 724d41cb8fb..4d4af653552 100644
--- a/doc/smart-switch/BFD/SmartSwitchDpuLivenessUsingBfd.md
+++ b/doc/smart-switch/BFD/SmartSwitchDpuLivenessUsingBfd.md
@@ -1,269 +1,269 @@
-## SmartSwitch - NPU-DPU liveness detection using BFD
-
-
-- [About this Manual](#about-this-manual)
-- [Definitions/Abbreviation](#definitionsabbreviation)
-- [1. Requirements Overview](#1-requirements-overview)
- - [1.1 Functional Requirements](#11-functional-requirements)
- - [1.2 Scale Requirements](#12-scale-requirements)
- - [1.3 Default values](#13-default-values)
-- [2. Modules Design](#2-modules-design)
- - [2.1 APP\_DB changes](#21-app_db-changes)
- - [2.2 SmartSwitch NPU-DPU BFD sessions](#22-smartswitch-npu-dpu-bfd-sessions)
- - [2.3 BFD Active-Passive mode](#23-bfd-active-passive-mode)
- - [2.4 DPU FRR Changes](#24-dpu-frr-changes)
- - [2.5 DPU Linux IPTables](#25-dpu-linux-iptables)
- - [2.6 NPU BFD session and VNET\_ROUTE\_TUNNEL](#26-npu-bfd-session-and-vnet_route_tunnel)
- - [2.7 DPU BFD session state Updates](#27-dpu-bfd-session-state-updates)
- - [2.8 NPU-DPU midplane state change and BFD session update](#28-npu-dpu-midplane-state-change-and-bfd-session-update)
- - [2.9 DPU BFD Host trap entries](#29-dpu-bfd-host-trap-entries)
- - [2.10 VNET Route and BFD session updates](#210-vnet-route-and-bfd-session-updates)
-
-###### Revision
-
-| Rev | Date | Author | Change Description |
-|:---:|:-----------:|:---------------------:|-----------------------------------|
-| 0.1 | 03/01/2024 | Kumaresh Perumal | Initial version |
-| 0.2 | 03/12/2024 | Kumaresh Perumal | Update review comments |
-| 0.3 | 03/13/2024 | Kumaresh Perumal | Update BFD table in STATE_DB |
-| 0.4| 03/20/2024 | Kumaresh Perumal | Update ACL usage |
-| 1.0| 03/26/2024| Kumaresh Perumal| Update with BFD Trap, Rx/Tx timers in APP_DB|
-|1.1| 05/28/2024 | Kumaresh Perumal | BFD session state updates to HA Scope state DB|
-|1.2| 12/01/2024 | Abdel Baig | Update DPU session state, FRR changes, orchagent changes|
-
-# About this Manual
-This document provides general information about the NPU-DPU liveness detection using BFD probes between NPU and DPU.
-
-# Definitions/Abbreviation
-
-| | |
-|--------------------------|------------------------------------------|
-| BFD | Bidirectional Forwarding Detection |
-| NPU | Network Processing Unit |
-| DPU | Data Processing Unit |
-| FRR | Open source routing stack |
-
-# 1. Requirements Overview
-
-## 1.1 Functional Requirements
-
-- BFD session(Active mode) in NPU using NPU's BFD H/W offload feature.
-
-- BFD session(Passive mode) in DPU using FRR.
-
-- BFD session between NPU and local DPU and remote DPU based on HA DPU
- pair.
-
-## 1.2 Scale Requirements
-
-- 64 BFD active sessions from NPU to each DPU in a T1 cluster.
-
-- 8 BFD passive sessions from DPU to all NPUs in a T1 cluster.
-
-Note: Scale requirements will double when BFD sessions need to be created for both IPv4 and IPv6.
-
-## 1.3 Default values
-
-- BFD TX_INTERVAL -- 100 msec(might change)
-
-- BFD_RX_INTERVAL - 100 msec(might change)
-
-- BFD session detect time multiplier - 3
-
-- BFD session type: Active on NPU and Passive on DPU
-
-- BFD mode: Multihop mode for sessions between NPU and remote DPU
-
-# 2. Modules Design
-## 2.1 APP_DB changes
-Existing VNET_ROUTE_TUNNEL_TABLE is updated to include BFD Rx and Tx timers. Overlay ECMP feature uses the default of one second and Smartswitch can have aggressive timers due to less number of BFD sessions.
-
-Existing
-```
-{% raw %} # ignore this line please
-VNET_ROUTE_TUNNEL_TABLE:{{vnet_name}}:{{prefix}}
- "endpoint": {{ip_address1},{ip_address2},...}
- "endpoint_monitor": {{ip_address1},{ip_address2},...} (OPTIONAL)
- "mac_address":{{mac_address1},{mac_address2},...} (OPTIONAL)
- "vni": {{vni1},{vni2},...} (OPTIONAL)
- "weight": {{w1},{w2},...} (OPTIONAL)
- “profile”: {{profile_name}} (OPTIONAL)
-{% endraw %} # ignore this line please
-```
-
-Proposed changes
-```
-{% raw %} # ignore this line please
-VNET_ROUTE_TUNNEL_TABLE:{{vnet_name}}:{{prefix}}
- "endpoint": {{ip_address1},{ip_address2},...}
- "endpoint_monitor": {{ip_address1},{ip_address2},...} (OPTIONAL)
- "mac_address":{{mac_address1},{mac_address2},...} (OPTIONAL)
- "vni": {{vni1},{vni2},...} (OPTIONAL)
- "weight": {{w1},{w2},...} (OPTIONAL)
- “profile”: {{profile_name}} (OPTIONAL)
- "rx_monitor_timer": {time in milliseconds}
- "tx_monitor_timer": {time in milliseconds}
-{% endraw %} # ignore this line please
-```
-
-## 2.2 SmartSwitch NPU-DPU BFD sessions
-
-In a Smartswitch deployment, BFD sessions are created between NPU and
-DPUs. Each T1 cluster has 8 T1s and 8 DPUs in each T1. To detect the
-liveness of each DPU in the cluster, NPU creates Active BFD sessions to
-all 64 DPUs and each DPU creates passive BFD sessions to all NPUs in the
-cluster. When BFD keepalives are not detected for certain interval, BFD
-sessions are marked as down and corresponding action is performed.
-Multihop BFD sessions are created between NPU and a remote DPU.
-
-
-
-## 2.3 BFD Active-Passive mode
-
-HA manager(hamgrd) in NPU creates DPU routing rules for DPU-level HA using VNET_ROUTE_TUNNEL_TABLE which will trigger bfdOrch to create BFD Active session with local and peer information. NPU supports BFD hardware offload, so hardware starts generating BFD packets to the peer.
-
-HA manager also creates another BFD passive multihop session in DPU using BFD_SESSION_TABLE in APP_DB with local DPU PA and peer NPU PAs. BfdOrch checks the platform SAI capability for BFD offload support and if it's unsupported, FRR is configured to trigger BFD sessions. BfdOrch creates BFD_SOFTWARE_SESSION_TABLE entry in STATE_DB with same field-value as passed from BFD_SESSION_TABLE. This allows flexibiliy in setting session type and other parameters from hamgrd.
-There is no support for TSA with software BFD sessions.
-
-A new manager called BfdMgr is added in bgpcfgd and is instantiated only if software_bfd is enabled in the FEATURE table. It monitors for changes in BFD_SOFTWARE_SESSION_TABLE in STATE_DB, and adds or removes BFD sessions in FRR if entries are added or removed in STATE_DB. The keys used in STATE_DB (vrf, interface, peer address) are different from keys used in FRR (vrf, interface, multihop, peer, local). If multihop or local-addr fields are modified in STATE_DB entry, then existing BFD session in and a new one added. Changes to any other fields simply update the existing BFD session in FRR without removing/re-adding. The only supported session type in STATE_DB is async_active. If this session type is set then an active sessions is created in FRR. If "type" field is not set or set to any other value (eg: async_passive) then a passive BFD session is created in FRR.
-
-Trigger for HA manager to create BFD sessions will be detailed in HA HLD.
-
-
-
-BFD passive sessions in DPU waits for BFD control packets from NPU's
-active session. When FRR stack receives BFD packets from active sessions
-in NPU, it starts responding. After the initial handshake, BFD sessions
-are up. When active session doesn't receive control packets for the
-configured BFD timeout period, session is set to DOWN and corresponding
-action is taken.
-
-
-
-## 2.4 DPU FRR Changes
-
-Update FRR supervisor config file to automatically start python script
-(bfdmon) to monitor for BFD session states in FRR if software_bfd is
-enabled in the FEATURE table. BFD Daemon will automatically be started by
-BfdMgr running as part of bgpcfgd.
-
-## 2.5 DPU Linux IPTables
-
-New rules need to be added in the kernel to allow BFD packets to be
-processed by the kernel and FRR stack. All packets matching BFD UDP(3784
-and 4784).
-
-***sudo iptables \--insert INPUT 5 -p udp \--dport 4784 -j ACCEPT***
-
-***sudo iptables \--insert INPUT 5 -p udp \--dport 3784 -j ACCEPT***
-
-These rules can be added as part of caclmgrd script during initialization by checking the DEVICE_METADATA object and attribute "switch_type: DPU" in CONFIG_DB.
-
-## 2.6 NPU BFD session and VNET_ROUTE_TUNNEL
-
-Overlay ECMP HLD describes how BFD session UP/Down changes the route to
-VIP of a SDN appliance. In Overlay ECMP feature, all the nexthops are
-VxLAN tunnel nexthops and the route to VIP is updated with primary or
-secondary ECMP group based on the BFD session up/down state change. In
-Smartswitch deployment, when a DPU VIP has nexthop local to
-NPU, nexthop will be a regular IP nexthop instead of a VxLAN NH.
-
-When HA manager receives HA config update, it will create VNET Route tunnel table and that triggers BFD session creation in NPU. These BFD sessions are hardware offloaded to NPU.
-
-
-
-## 2.7 DPU BFD session state Updates
-
-
-| Table | Key | Field | Description |
-| :-------------------: | :---: | :----------------: |:-----------:
-| DASH_BFD_PROBE_STATE | | | Per-DPU state DB Table |
-| | N/A| v4_bfd_up_sessions | List of V4 BFD session IPs in UP state|
-| | | v6_bfd_up_sessions | List of V6 BFD session IPs in UP state|
-
-This state_db table stores all the V4 and V6 BFD sessions that are in up state. New python module called bfdmon is created in BGPCfgd which continuously queries (every 2 seconds by default) all BFD 'UP' sessions in FRR and updates the DASH_BFD_PROBE_STATE table with all the peer NPU IPs in 'v4_bfd_up_sessions' and 'v6_bfd_up_sessions' fields.
-
-Example table:
-```
-redis-cli -n 6 hgetall "DASH_BFD_PROBE_STATE"
-1) "v4_bfd_up_sessions"
-2) "[\"1.0.2.2\", \"1.0.3.2\"]"
-3) "v6_bfd_up_sessions"
-4) "[\"1:0:3::2\", \"1:0:2::2\"]"
-```
-
-HA Manager maintains an external facing state table(DASH_HA_SCOPE_STATE) in NPU to publish all the required state information per VDPU that can be queried by the controller. To provide state of BFD sessions established between the local DPU and NPUs, HA manager queries DASH_BFD_PROBE_STATE table per-DPU and updates DASH_HA_SCOPE_STATE fields(local_vdpu_up_bfd_sessions_v4 and local_vdpu_up_bfd_sessions_v6)
-
-For more details about the HA state table and the fields, please refer to [Smartswitch HA HLD](https://github.com/r12f/SONiC/blob/user/r12f/ha2/doc/smart-switch/high-availability/smart-switch-ha-detailed-design.md)
-
-## 2.8 NPU-DPU midplane state change and BFD session update
-
-When NPU-DPU midplane interface goes down due to some trigger or platform changes, PMON module updates the midplane NetDev interface state in DPU_STATE DB and trigger a notification for link state change. HA manager listens to these updates and bring down the BFD by applying ingress ACL rules or updating NPU->DPU links. This will bring down the local and remote BFD sessions between NPU and DPU. ACL can be attached to NPU-DPU interconnect interface to drop BFD packets from DPU.
-
-Note: This is out of scope of this document, Smartswitch HA HLD will have more details as HA manager listens to all FSM changes from the controller and PMON changes. For more details, please refere to Unplanned Events section in SmartSwitch HA HLD.
-
-## 2.9 DPU BFD Host trap entries
-To avoid BFD packets getting delayed or congested with other data traffic, BFD host_trap entries are created to redirect BFD control packets to a separate queue. This can be done during system initialization like other COPP rules generated for BGP, LLDP etc.,
-
-Hostif trap SAI attribute for BFD is SAI_HOSTIF_TRAP_TYPE_BFD and SAI_HOSTIF_TRAP_TYPE_BFDV6. This covers both single-hop and multi-hop BFD packets.
-
-## 2.10 VNET Route and BFD session updates
-Some of the scenarios when VIP is pointing to Local and Remote nexthops
-and the BFD session state changes between NPU and DPU. In the below
-scenarios, local NH is the IP nexthop to local DPU and Remote NH is the
-VxLAN tunnel nexthop to remote NPU.
-
-```
-
-+-------------------------+--------------+---------------+---------------+
-|** VNET Route** | **Primary** | **BFD session | **Result** |
-| | | update** | |
-+=========================+==============+===============+===============+
-| VIP: {Local NH, Remote | Local NH | Local NH UP | VIP: Local NH |
-| NH}. | | | |
-| | | Remote NH UP | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Local NH, Remote | Local NH | Local NH Down | VIP: Remote |
-| NH} | | | NH |
-| | | Remote NH UP | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Local NH, Remote | Remote NH | Local NH UP | VIP: Remote |
-| NH} | | | NH |
-| | | Remote NH UP | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Local NH, Remote | Remote NH | Local NH UP | VIP: Local NH |
-| NH} | | | |
-| | | Remote NH | |
-| | | Down | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {local NH, Remote | Local | Local NH Down | VIP:Primary NH|
-| NH} | /Remote NH | | |
-| | | Remote NH | |
-| | | Down | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Remote NH1, | Remote NH1 | Remote NH1 UP | VIP: Remote |
-| Remote NH2} | | | NH1 |
-| | | Remote NH2 UP | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Remote NH1, | Remote NH1 | Remote NH1 | VIP: Remote |
-| Remote NH2} | | DOWN | NH2 |
-| | | | |
-| | | Remote NH2 UP | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Remote NH1, | Remote NH2 | Remote NH1 UP | VIP: Remote |
-| Remote NH2} | | | NH2 |
-| | | Remote NH2 UP | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Remote NH1, | Remote NH2 | Remote NH1 UP | VIP: Remote |
-| Remote NH2} | | | NH1 |
-| | | Remote NH2 | |
-| | | Down | |
-+-------------------------+--------------+---------------+---------------+
-| VIP: {Remote NH1, | Remote | Remote NH1 | VIP:Primary NH|
-| Remote NH2} | NH1/NH2 | Down | |
-| | | | |
-| | | Remote NH2 | |
-| | | Down | |
-+-------------------------+--------------+---------------+---------------+
-
-```
+## SmartSwitch - NPU-DPU liveness detection using BFD
+
+
+- [About this Manual](#about-this-manual)
+- [Definitions/Abbreviation](#definitionsabbreviation)
+- [1. Requirements Overview](#1-requirements-overview)
+ - [1.1 Functional Requirements](#11-functional-requirements)
+ - [1.2 Scale Requirements](#12-scale-requirements)
+ - [1.3 Default values](#13-default-values)
+- [2. Modules Design](#2-modules-design)
+ - [2.1 APP\_DB changes](#21-app_db-changes)
+ - [2.2 SmartSwitch NPU-DPU BFD sessions](#22-smartswitch-npu-dpu-bfd-sessions)
+ - [2.3 BFD Active-Passive mode](#23-bfd-active-passive-mode)
+ - [2.4 DPU FRR Changes](#24-dpu-frr-changes)
+ - [2.5 DPU Linux IPTables](#25-dpu-linux-iptables)
+ - [2.6 NPU BFD session and VNET\_ROUTE\_TUNNEL](#26-npu-bfd-session-and-vnet_route_tunnel)
+ - [2.7 DPU BFD session state Updates](#27-dpu-bfd-session-state-updates)
+ - [2.8 NPU-DPU midplane state change and BFD session update](#28-npu-dpu-midplane-state-change-and-bfd-session-update)
+ - [2.9 DPU BFD Host trap entries](#29-dpu-bfd-host-trap-entries)
+ - [2.10 VNET Route and BFD session updates](#210-vnet-route-and-bfd-session-updates)
+
+###### Revision
+
+| Rev | Date | Author | Change Description |
+|:---:|:-----------:|:---------------------:|-----------------------------------|
+| 0.1 | 03/01/2024 | Kumaresh Perumal | Initial version |
+| 0.2 | 03/12/2024 | Kumaresh Perumal | Update review comments |
+| 0.3 | 03/13/2024 | Kumaresh Perumal | Update BFD table in STATE_DB |
+| 0.4| 03/20/2024 | Kumaresh Perumal | Update ACL usage |
+| 1.0| 03/26/2024| Kumaresh Perumal| Update with BFD Trap, Rx/Tx timers in APP_DB|
+|1.1| 05/28/2024 | Kumaresh Perumal | BFD session state updates to HA Scope state DB|
+|1.2| 12/01/2024 | Abdel Baig | Update DPU session state, FRR changes, orchagent changes|
+
+# About this Manual
+This document provides general information about the NPU-DPU liveness detection using BFD probes between NPU and DPU.
+
+# Definitions/Abbreviation
+
+| | |
+|--------------------------|------------------------------------------|
+| BFD | Bidirectional Forwarding Detection |
+| NPU | Network Processing Unit |
+| DPU | Data Processing Unit |
+| FRR | Open source routing stack |
+
+# 1. Requirements Overview
+
+## 1.1 Functional Requirements
+
+- BFD session(Active mode) in NPU using NPU's BFD H/W offload feature.
+
+- BFD session(Passive mode) in DPU using FRR.
+
+- BFD session between NPU and local DPU and remote DPU based on HA DPU
+ pair.
+
+## 1.2 Scale Requirements
+
+- 64 BFD active sessions from NPU to each DPU in a T1 cluster.
+
+- 8 BFD passive sessions from DPU to all NPUs in a T1 cluster.
+
+Note: Scale requirements will double when BFD sessions need to be created for both IPv4 and IPv6.
+
+## 1.3 Default values
+
+- BFD TX_INTERVAL -- 100 msec(might change)
+
+- BFD_RX_INTERVAL - 100 msec(might change)
+
+- BFD session detect time multiplier - 3
+
+- BFD session type: Active on NPU and Passive on DPU
+
+- BFD mode: Multihop mode for sessions between NPU and remote DPU
+
+# 2. Modules Design
+## 2.1 APP_DB changes
+Existing VNET_ROUTE_TUNNEL_TABLE is updated to include BFD Rx and Tx timers. Overlay ECMP feature uses the default of one second and Smartswitch can have aggressive timers due to less number of BFD sessions.
+
+Existing
+```
+{% raw %} # ignore this line please
+VNET_ROUTE_TUNNEL_TABLE:{{vnet_name}}:{{prefix}}
+ "endpoint": {{ip_address1},{ip_address2},...}
+ "endpoint_monitor": {{ip_address1},{ip_address2},...} (OPTIONAL)
+ "mac_address":{{mac_address1},{mac_address2},...} (OPTIONAL)
+ "vni": {{vni1},{vni2},...} (OPTIONAL)
+ "weight": {{w1},{w2},...} (OPTIONAL)
+ “profile”: {{profile_name}} (OPTIONAL)
+{% endraw %} # ignore this line please
+```
+
+Proposed changes
+```
+{% raw %} # ignore this line please
+VNET_ROUTE_TUNNEL_TABLE:{{vnet_name}}:{{prefix}}
+ "endpoint": {{ip_address1},{ip_address2},...}
+ "endpoint_monitor": {{ip_address1},{ip_address2},...} (OPTIONAL)
+ "mac_address":{{mac_address1},{mac_address2},...} (OPTIONAL)
+ "vni": {{vni1},{vni2},...} (OPTIONAL)
+ "weight": {{w1},{w2},...} (OPTIONAL)
+ “profile”: {{profile_name}} (OPTIONAL)
+ "rx_monitor_timer": {time in milliseconds}
+ "tx_monitor_timer": {time in milliseconds}
+{% endraw %} # ignore this line please
+```
+
+## 2.2 SmartSwitch NPU-DPU BFD sessions
+
+In a Smartswitch deployment, BFD sessions are created between NPU and
+DPUs. Each T1 cluster has 8 T1s and 8 DPUs in each T1. To detect the
+liveness of each DPU in the cluster, NPU creates Active BFD sessions to
+all 64 DPUs and each DPU creates passive BFD sessions to all NPUs in the
+cluster. When BFD keepalives are not detected for certain interval, BFD
+sessions are marked as down and corresponding action is performed.
+Multihop BFD sessions are created between NPU and a remote DPU.
+
+
+
+## 2.3 BFD Active-Passive mode
+
+HA manager(hamgrd) in NPU creates DPU routing rules for DPU-level HA using VNET_ROUTE_TUNNEL_TABLE which will trigger bfdOrch to create BFD Active session with local and peer information. NPU supports BFD hardware offload, so hardware starts generating BFD packets to the peer.
+
+HA manager also creates another BFD passive multihop session in DPU using BFD_SESSION_TABLE in APP_DB with local DPU PA and peer NPU PAs. BfdOrch checks the platform SAI capability for BFD offload support and if it's unsupported, FRR is configured to trigger BFD sessions. BfdOrch creates BFD_SOFTWARE_SESSION_TABLE entry in STATE_DB with same field-value as passed from BFD_SESSION_TABLE. This allows flexibiliy in setting session type and other parameters from hamgrd.
+There is no support for TSA with software BFD sessions.
+
+A new manager called BfdMgr is added in bgpcfgd and is instantiated only if software_bfd is enabled in the FEATURE table. It monitors for changes in BFD_SOFTWARE_SESSION_TABLE in STATE_DB, and adds or removes BFD sessions in FRR if entries are added or removed in STATE_DB. The keys used in STATE_DB (vrf, interface, peer address) are different from keys used in FRR (vrf, interface, multihop, peer, local). If multihop or local-addr fields are modified in STATE_DB entry, then existing BFD session in and a new one added. Changes to any other fields simply update the existing BFD session in FRR without removing/re-adding. The only supported session type in STATE_DB is async_active. If this session type is set then an active sessions is created in FRR. If "type" field is not set or set to any other value (eg: async_passive) then a passive BFD session is created in FRR.
+
+Trigger for HA manager to create BFD sessions will be detailed in HA HLD.
+
+
+
+BFD passive sessions in DPU waits for BFD control packets from NPU's
+active session. When FRR stack receives BFD packets from active sessions
+in NPU, it starts responding. After the initial handshake, BFD sessions
+are up. When active session doesn't receive control packets for the
+configured BFD timeout period, session is set to DOWN and corresponding
+action is taken.
+
+
+
+## 2.4 DPU FRR Changes
+
+Update FRR supervisor config file to automatically start python script
+(bfdmon) to monitor for BFD session states in FRR if software_bfd is
+enabled in the FEATURE table. BFD Daemon will automatically be started by
+BfdMgr running as part of bgpcfgd.
+
+## 2.5 DPU Linux IPTables
+
+New rules need to be added in the kernel to allow BFD packets to be
+processed by the kernel and FRR stack. All packets matching BFD UDP(3784
+and 4784).
+
+***sudo iptables \--insert INPUT 5 -p udp \--dport 4784 -j ACCEPT***
+
+***sudo iptables \--insert INPUT 5 -p udp \--dport 3784 -j ACCEPT***
+
+These rules can be added as part of caclmgrd script during initialization by checking the DEVICE_METADATA object and attribute "switch_type: DPU" in CONFIG_DB.
+
+## 2.6 NPU BFD session and VNET_ROUTE_TUNNEL
+
+Overlay ECMP HLD describes how BFD session UP/Down changes the route to
+VIP of a SDN appliance. In Overlay ECMP feature, all the nexthops are
+VxLAN tunnel nexthops and the route to VIP is updated with primary or
+secondary ECMP group based on the BFD session up/down state change. In
+Smartswitch deployment, when a DPU VIP has nexthop local to
+NPU, nexthop will be a regular IP nexthop instead of a VxLAN NH.
+
+When HA manager receives HA config update, it will create VNET Route tunnel table and that triggers BFD session creation in NPU. These BFD sessions are hardware offloaded to NPU.
+
+
+
+## 2.7 DPU BFD session state Updates
+
+
+| Table | Key | Field | Description |
+| :-------------------: | :---: | :----------------: |:-----------:
+| DASH_BFD_PROBE_STATE | | | Per-DPU state DB Table |
+| | N/A| v4_bfd_up_sessions | List of V4 BFD session IPs in UP state|
+| | | v6_bfd_up_sessions | List of V6 BFD session IPs in UP state|
+
+This state_db table stores all the V4 and V6 BFD sessions that are in up state. New python module called bfdmon is created in BGPCfgd which continuously queries (every 2 seconds by default) all BFD 'UP' sessions in FRR and updates the DASH_BFD_PROBE_STATE table with all the peer NPU IPs in 'v4_bfd_up_sessions' and 'v6_bfd_up_sessions' fields.
+
+Example table:
+```
+redis-cli -n 6 hgetall "DASH_BFD_PROBE_STATE"
+1) "v4_bfd_up_sessions"
+2) "[\"1.0.2.2\", \"1.0.3.2\"]"
+3) "v6_bfd_up_sessions"
+4) "[\"1:0:3::2\", \"1:0:2::2\"]"
+```
+
+HA Manager maintains an external facing state table(DASH_HA_SCOPE_STATE) in NPU to publish all the required state information per VDPU that can be queried by the controller. To provide state of BFD sessions established between the local DPU and NPUs, HA manager queries DASH_BFD_PROBE_STATE table per-DPU and updates DASH_HA_SCOPE_STATE fields(local_vdpu_up_bfd_sessions_v4 and local_vdpu_up_bfd_sessions_v6)
+
+For more details about the HA state table and the fields, please refer to [Smartswitch HA HLD](https://github.com/r12f/SONiC/blob/user/r12f/ha2/doc/smart-switch/high-availability/smart-switch-ha-detailed-design.md)
+
+## 2.8 NPU-DPU midplane state change and BFD session update
+
+When NPU-DPU midplane interface goes down due to some trigger or platform changes, PMON module updates the midplane NetDev interface state in DPU_STATE DB and trigger a notification for link state change. HA manager listens to these updates and bring down the BFD by applying ingress ACL rules or updating NPU->DPU links. This will bring down the local and remote BFD sessions between NPU and DPU. ACL can be attached to NPU-DPU interconnect interface to drop BFD packets from DPU.
+
+Note: This is out of scope of this document, Smartswitch HA HLD will have more details as HA manager listens to all FSM changes from the controller and PMON changes. For more details, please refer to Unplanned Events section in SmartSwitch HA HLD.
+
+## 2.9 DPU BFD Host trap entries
+To avoid BFD packets getting delayed or congested with other data traffic, BFD host_trap entries are created to redirect BFD control packets to a separate queue. This can be done during system initialization like other COPP rules generated for BGP, LLDP etc.,
+
+Hostif trap SAI attribute for BFD is SAI_HOSTIF_TRAP_TYPE_BFD and SAI_HOSTIF_TRAP_TYPE_BFDV6. This covers both single-hop and multi-hop BFD packets.
+
+## 2.10 VNET Route and BFD session updates
+Some of the scenarios when VIP is pointing to Local and Remote nexthops
+and the BFD session state changes between NPU and DPU. In the below
+scenarios, local NH is the IP nexthop to local DPU and Remote NH is the
+VxLAN tunnel nexthop to remote NPU.
+
+```
+
++-------------------------+--------------+---------------+---------------+
+|** VNET Route** | **Primary** | **BFD session | **Result** |
+| | | update** | |
++=========================+==============+===============+===============+
+| VIP: {Local NH, Remote | Local NH | Local NH UP | VIP: Local NH |
+| NH}. | | | |
+| | | Remote NH UP | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Local NH, Remote | Local NH | Local NH Down | VIP: Remote |
+| NH} | | | NH |
+| | | Remote NH UP | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Local NH, Remote | Remote NH | Local NH UP | VIP: Remote |
+| NH} | | | NH |
+| | | Remote NH UP | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Local NH, Remote | Remote NH | Local NH UP | VIP: Local NH |
+| NH} | | | |
+| | | Remote NH | |
+| | | Down | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {local NH, Remote | Local | Local NH Down | VIP:Primary NH|
+| NH} | /Remote NH | | |
+| | | Remote NH | |
+| | | Down | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Remote NH1, | Remote NH1 | Remote NH1 UP | VIP: Remote |
+| Remote NH2} | | | NH1 |
+| | | Remote NH2 UP | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Remote NH1, | Remote NH1 | Remote NH1 | VIP: Remote |
+| Remote NH2} | | DOWN | NH2 |
+| | | | |
+| | | Remote NH2 UP | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Remote NH1, | Remote NH2 | Remote NH1 UP | VIP: Remote |
+| Remote NH2} | | | NH2 |
+| | | Remote NH2 UP | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Remote NH1, | Remote NH2 | Remote NH1 UP | VIP: Remote |
+| Remote NH2} | | | NH1 |
+| | | Remote NH2 | |
+| | | Down | |
++-------------------------+--------------+---------------+---------------+
+| VIP: {Remote NH1, | Remote | Remote NH1 | VIP:Primary NH|
+| Remote NH2} | NH1/NH2 | Down | |
+| | | | |
+| | | Remote NH2 | |
+| | | Down | |
++-------------------------+--------------+---------------+---------------+
+
+```
diff --git a/doc/smart-switch/high-availability/eni-based-forwarding.md b/doc/smart-switch/high-availability/eni-based-forwarding.md
index ca21e729674..8c256300c55 100644
--- a/doc/smart-switch/high-availability/eni-based-forwarding.md
+++ b/doc/smart-switch/high-availability/eni-based-forwarding.md
@@ -68,11 +68,11 @@ Packet Forwarding from NPU to local and remote DPU's are clearly explained in th
### Packet Flow ###
-**Case 1: Packet lands directly on NPU which has the currrent Active ENI**
+**Case 1: Packet lands directly on NPU which has the current Active ENI**
-**Case 2: Packet lands NPU which has the currrent Standby ENI**
+**Case 2: Packet lands NPU which has the current Standby ENI**
@@ -84,7 +84,7 @@ Packet Forwarding from NPU to local and remote DPU's are clearly explained in th
ENI based forwarding requires the switch to understand the relationship between the packet and ENI, and ENI and DPU.
-* Each DPU is represented as a PA (public address). Unlike VIP, PA does't have to be visible from the entire cloud infrastructure
+* Each DPU is represented as a PA (public address). Unlike VIP, PA doesn't have to be visible from the entire cloud infrastructure
* Every ENI should be a part of T1 cluster
* Each packet can be identified as belonging to that switch using VIP and VNI
* Forwarding can be to local DPU or remote DPU over L3 VxLAN
diff --git a/doc/smart-switch/high-availability/smart-switch-ha-detailed-design.md b/doc/smart-switch/high-availability/smart-switch-ha-detailed-design.md
index 45576e4b2ea..fbdc8ab09cf 100644
--- a/doc/smart-switch/high-availability/smart-switch-ha-detailed-design.md
+++ b/doc/smart-switch/high-availability/smart-switch-ha-detailed-design.md
@@ -446,7 +446,7 @@ The following tables will be programmed either by SDN controller or by the netwo
To show the current state of HA, the states will be aggregated by `hamgrd` and store in the HA scope table as below.
-> Because this state table is relatively large, the fields are splited into a few sections below.
+> Because this state table is relatively large, the fields are split into a few sections below.
###### 2.2.1.1.1. Table key
@@ -711,7 +711,7 @@ Once the packet lands on an ENI, we should have the following counters to monito
#### 3.3.3. ENI-level pipeline drop counters (Per-ENI)
-When the packet is landed on the ENI going throught each match stages, it might be dropped due to no entries can be matched, such as routing or CA-PA mapping. In order to show these drops, we should have the following counters:
+When the packet is landed on the ENI going through each match stages, it might be dropped due to no entries can be matched, such as routing or CA-PA mapping. In order to show these drops, we should have the following counters:
| Name | Description |
| -------------- | ----------- |
@@ -781,7 +781,7 @@ To monitor how it works, we should have the following counters on HA set level:
| Name | Description |
| --- | --- |
| SAI_HA_SET_STAT_CP_DATA_CHANNEL_CONNECT_ATTEMPTED | Number of connect calls for establishing the data channel. |
-| SAI_HA_SET_STAT_CP_DATA_CHANNEL_CONNECT_RECEIVED | Number of connect calls received to estabilish the data channel. |
+| SAI_HA_SET_STAT_CP_DATA_CHANNEL_CONNECT_RECEIVED | Number of connect calls received to establish the data channel. |
| SAI_HA_SET_STAT_CP_DATA_CHANNEL_CONNECT_SUCCEEDED | Number of connect calls that succeeded. |
| SAI_HA_SET_STAT_CP_DATA_CHANNEL_CONNECT_FAILED | Number of connect calls that failed because of any reason other than timeout / unreachable. |
| SAI_HA_SET_STAT_CP_DATA_CHANNEL_CONNECT_REJECTED | Number of connect calls that rejected due to certs and etc. |
diff --git a/doc/smart-switch/high-availability/smart-switch-ha-dpu-scope-dpu-driven-setup.md b/doc/smart-switch/high-availability/smart-switch-ha-dpu-scope-dpu-driven-setup.md
index 1990cf11ee0..34926d40d13 100644
--- a/doc/smart-switch/high-availability/smart-switch-ha-dpu-scope-dpu-driven-setup.md
+++ b/doc/smart-switch/high-availability/smart-switch-ha-dpu-scope-dpu-driven-setup.md
@@ -54,7 +54,7 @@ Many things in this setup will shares the same or very similar approach as the E
In SmartSwitch HA design, there are a few key characteristics that defines the high level behavior of HA:
-- **HA pairing**: How the ENIs are placed amoung all DPUs to form the HA set?
+- **HA pairing**: How the ENIs are placed among all DPUs to form the HA set?
- **HA owner**: Who drives the HA state machine on behalf of SDN controller?
- **HA scope**: At which level, the HA state machine is managed? This determines how the traffic is forwarded from NPU to DPU.
- **HA mode**: How the DPUs coordinate with each other to achieve HA?
@@ -82,7 +82,7 @@ With DPU-level HA scope, the HA state is controlled at the DPU level. This means
### 4.2. DPU-level NPU to DPU traffic forwarding
-Due to the essense of the DPU-level HA scope, the traffic forwarding from NPU to DPU will be done on DPU level:
+Due to the essence of the DPU-level HA scope, the traffic forwarding from NPU to DPU will be done on DPU level:
- Each DPU pair will use a dedicated VIP per HA scope for traffic forwarding from NPU to DPU.
- All VIPs for all DPUs in the SmartSwitch will be pre-programmed into the NPU and advertised to the network as a single VIP range (or subnet).
diff --git a/doc/smart-switch/high-availability/smart-switch-ha-hamgrd.md b/doc/smart-switch/high-availability/smart-switch-ha-hamgrd.md
index cca9d6736e3..fd964dc34ac 100644
--- a/doc/smart-switch/high-availability/smart-switch-ha-hamgrd.md
+++ b/doc/smart-switch/high-availability/smart-switch-ha-hamgrd.md
@@ -121,7 +121,7 @@ Since HA set is mostly only used for defining the list of vDPUs that being paire
- It aggregates all information from the global config and vDPUs to update its own state.
- After information is ready:
- If the scope is `dpu`, it will setup the DPU level forwarding rule for the HA set.
- - For any vDPU that is local to the current swtich, it programs the DPU side HA set table, so the HA set info can be used by the ENI.
+ - For any vDPU that is local to the current switch, it programs the DPU side HA set table, so the HA set info can be used by the ENI.
```mermaid
flowchart LR
diff --git a/doc/smart-switch/high-availability/smart-switch-ha-hld.md b/doc/smart-switch/high-availability/smart-switch-ha-hld.md
index 88873601637..04260d63b05 100644
--- a/doc/smart-switch/high-availability/smart-switch-ha-hld.md
+++ b/doc/smart-switch/high-availability/smart-switch-ha-hld.md
@@ -3,7 +3,7 @@
| Rev | Date | Author | Change Description |
| --- | ---- | ------ | ------------------ |
| 0.1 | 08/09/2023 | Riff Jiang | Initial version |
-| 0.2 | 08/10/2023 | Riff Jiang | Simpified ENI-level traffic control, primary election algorithm |
+| 0.2 | 08/10/2023 | Riff Jiang | Simplified ENI-level traffic control, primary election algorithm |
| 0.3 | 08/14/2023 | Riff Jiang | Added DPU level standalone support |
| 0.4 | 08/17/2023 | Riff Jiang | Redesigned HA control plane data channel |
| 0.5 | 10/14/2023 | Riff Jiang | Merged resource placement and topology section and moved detailed design out for better readability |
@@ -37,7 +37,7 @@
1. [5.1. Working with upstream service](#51-working-with-upstream-service)
2. [5.2. HA control plane overview](#52-ha-control-plane-overview)
1. [5.2.1. HA control plane components](#521-ha-control-plane-components)
- 1. [5.2.1.1. ha containter](#5211-ha-containter)
+ 1. [5.2.1.1. ha container](#5211-ha-container)
2. [5.2.1.2. swbusd](#5212-swbusd)
3. [5.2.1.3. hamgrd](#5213-hamgrd)
2. [5.2.2. HA Control Plane Channels](#522-ha-control-plane-channels)
@@ -227,7 +227,7 @@ When designing HA for SmartSwitch, we have a few assumptions:
## 4. Network Physical Topology
-> Today, in [SONiC DASH HLD](../../dash/dash-sonic-hld.md), a DASH pipeline is modeled to be an ENI, although all the discussion below is generically appliable to other scenarios, but we will use ENI to refer the DASH pipeline for simplicity.
+> Today, in [SONiC DASH HLD](../../dash/dash-sonic-hld.md), a DASH pipeline is modeled to be an ENI, although all the discussion below is generically applicable to other scenarios, but we will use ENI to refer the DASH pipeline for simplicity.
### 4.1. ENI placement
@@ -323,7 +323,7 @@ Many customer tenants have restrictions on how many nodes can be impacted when u
* Update domain defines the groups of virtual machines and underlying physical hardware that can be rebooted at the same time.
* Fault domain defines the group of virtual machines that share a common power source and network switch.
-Since SmartSwitch is a shared network service, one single DPU could host multiple ENIs from the same UD or FD. And with the ENI-level setup, these restrictions could also be supported by simply batching the ENI failover based on the UD and FD information when upgrade or other maintainance work happens.
+Since SmartSwitch is a shared network service, one single DPU could host multiple ENIs from the same UD or FD. And with the ENI-level setup, these restrictions could also be supported by simply batching the ENI failover based on the UD and FD information when upgrade or other maintenance work happens.
#### 4.3.5. DPU to DPU communication for flow HA
@@ -413,7 +413,7 @@ Here is the overview of HA control plane, and we will walk through the component
#### 5.2.1. HA control plane components
-##### 5.2.1.1. ha containter
+##### 5.2.1.1. ha container
To support HA, we will need to add new programs that communicates between multiple smart switches, manages the HA state machine transition or syncing other data, such as flow info. These programs will be running in a new container called `ha`.
@@ -611,7 +611,7 @@ Probing local DPU is straightforward, we can directly set up the BFD session in
#### 6.1.3. BFD probing remote DPU
-We wiil use multi-hop BFD to probe the remote DPU with certain changes in NPU.
+We will use multi-hop BFD to probe the remote DPU with certain changes in NPU.
In order to make it work, we need the DPU IP to be advertised in the network, so that we can directly send BFD packet to it. With this, the data path will be looking like below:
@@ -1390,7 +1390,7 @@ To solve problem 2, we have 2 mechanisms:
With these 2 mechanisms, as long as we have 1 switch working, the traffic will be forwarded correctly.
-For detailed data path, please see "[Standy to active DPU tunnel](#4351-standby-to-active-dpu-tunnel)" section.
+For detailed data path, please see "[Standby to active DPU tunnel](#4351-standby-to-active-dpu-tunnel)" section.
#### 9.3.2. Switch power down or kernel crash
@@ -1513,7 +1513,7 @@ First, we need to check the DPU health signals:
At this moment, both DPU should be running fine, so we start to check the ENI status and data path status. To ensure we have the latest state, we will send the `DPURequestEnterStandalone` message with aggregated signals and ENI states to the peer DPU. And upon receiving the message, we will run the following checks:
1. If the signals from local DPU have "Card pinned to standalone", we return `Deny` to the peer DPU.
-2. Check "Manual Pinned" for manual opertaions:
+2. Check "Manual Pinned" for manual operations:
1. If the signals from local DPU have "Manual Pinned", which the peer DPU doesn't have, we return `Deny` to the peer DPU.
2. If the signals from peer DPU have "Manual Pinned", which the local DPU doesn't have, we return `Allow` to the peer DPU.
3. If both sides have "Manual Pinned", we return `Deny` and raise alert after retrying certain amount of times.
diff --git a/doc/smart-switch/high-availability/vnet_local_endpoint_forwarding.md b/doc/smart-switch/high-availability/vnet_local_endpoint_forwarding.md
index 95b4418b731..2f3ef2969ea 100644
--- a/doc/smart-switch/high-availability/vnet_local_endpoint_forwarding.md
+++ b/doc/smart-switch/high-availability/vnet_local_endpoint_forwarding.md
@@ -8,7 +8,7 @@ TODO: add packet flow diagram for the scenarios.
## Handling directly connected next hops (local DPU)
-Covered in [Overlay ECMP ehancements - support for directly conneced nexthops](https://github.com/sonic-net/SONiC/blob/master/doc/vxlan/Overlay%20ECMP%20ehancements.md#33-bfd-tx-rx-interval-parameter-and-support-for-directly-connected-nexthops).
+Covered in [Overlay ECMP enhancements - support for directly connected nexthops](https://github.com/sonic-net/SONiC/blob/master/doc/vxlan/Overlay%20ECMP%20ehancements.md#33-bfd-tx-rx-interval-parameter-and-support-for-directly-connected-nexthops).
A new field will be added the `VNET_ROUTE_TUNNEL_TABLE`:
diff --git a/doc/smart-switch/pmon/smartswitch-pmon.md b/doc/smart-switch/pmon/smartswitch-pmon.md
index b26e5d021be..5c0691469a4 100644
--- a/doc/smart-switch/pmon/smartswitch-pmon.md
+++ b/doc/smart-switch/pmon/smartswitch-pmon.md
@@ -667,7 +667,7 @@ return REBOOT_CAUSE_NON_HARDWARE + ', ' + 'kernel panic'
```
#### 2. DPU State
- * Added supporting fileds such as "time" and "reason" to show exactly where in the state progression the DPU failed. This will be helpful in fault isolation, DPU switchover decision, resiliency and recovery
+ * Added supporting fields such as "time" and "reason" to show exactly where in the state progression the DPU failed. This will be helpful in fault isolation, DPU switchover decision, resiliency and recovery
* Though this is platform implementation specific, in a multi vendor use case, there has to be a consistent way of storing and accessing the information.
* Store the state progression (dpu_midplane_link_state, dpu_control_plane_state, dpu_data_plane_state) on the host ChassisStateDB.
* get_state_info(self) will return an object with the ChassisStateDB data
@@ -1246,11 +1246,11 @@ root@sonic:/home/admin# show interfaces status
### 3.5 Console Management
The console access to smartswitch needs to support DPU access in addition to the switch.
* By default the management port should be connected to the switch CPU console
-* Once inside the switch, the DPUs should be accesssible from it.
+* Once inside the switch, the DPUs should be accessible from it.
#### 3.5.1 Dpu Console Utility
* Sonic now supports a DPU console utility "dpu-tty.py"
-* The scope of this is limited only to smartswitch paltforms
+* The scope of this is limited only to smartswitch platforms
* The user can invoke one or more DPU consoles as shown below by invoking the script "dpu-tty.py" with the module name option "-n dpu0"
```
diff --git a/doc/smart-switch/reboot/reboot-hld.md b/doc/smart-switch/reboot/reboot-hld.md
index f870be44f1e..6808ccd65f3 100644
--- a/doc/smart-switch/reboot/reboot-hld.md
+++ b/doc/smart-switch/reboot/reboot-hld.md
@@ -213,7 +213,7 @@ message RebootRequest {
string message = 3;
// Optional sub-components to reboot.
repeated types.Path subcomponents = 4;
- // Force reboot if sanity checks fail. (ex. uncommited configuration)
+ // Force reboot if sanity checks fail. (ex. uncommitted configuration)
bool force = 5;
}
diff --git a/doc/smart-switch/upgrade/dpu-upgrade-hld.md b/doc/smart-switch/upgrade/dpu-upgrade-hld.md
index 13ac94c2617..3d95c85a1f1 100644
--- a/doc/smart-switch/upgrade/dpu-upgrade-hld.md
+++ b/doc/smart-switch/upgrade/dpu-upgrade-hld.md
@@ -12,7 +12,7 @@
This document describes the high-level design of the sequence to independently upgrade a SmartSwitch DPU with minimal impact to other DPUs and the NPU, through GNOI API.
-#### 2.1 Depenedencies
+#### 2.1 Dependencies
The individual DPU upgrade process depends on the following components:
* Healthy DPU and NPU SONiC Host Services: The system service running on DPU that interact with the OS to execute the upgrade process.
* Healthy DPU and NPU SONiC GNMI: The GNOI service running on the DPU, which is responsible for handling GNOI requests for upgrades.
diff --git a/doc/snmp/extension-to-physical-entity-mib.md b/doc/snmp/extension-to-physical-entity-mib.md
index 4453606ece0..28bb4310f32 100644
--- a/doc/snmp/extension-to-physical-entity-mib.md
+++ b/doc/snmp/extension-to-physical-entity-mib.md
@@ -128,7 +128,7 @@ class DeviceBase(object):
raise NotImplementedError
```
-Second, add thermal list for PsuBase and SfpBase to reflect the actual hierarchy. Vender should initialize thermal list for PSU and SFP properly. Thermal control daemon should also retrieve thermal objects from PSU and SFP.
+Second, add thermal list for PsuBase and SfpBase to reflect the actual hierarchy. Vendor should initialize thermal list for PSU and SFP properly. Thermal control daemon should also retrieve thermal objects from PSU and SFP.
```python
class PsuBase(device_base.DeviceBase):
@@ -163,7 +163,7 @@ class PsuBase(device_base.DeviceBase):
retrieve
Returns:
- An object dervied from ThermalBase representing the specified thermal
+ An object derived from ThermalBase representing the specified thermal
"""
thermal = None
@@ -381,8 +381,8 @@ New test cases will be added to cover the new MIB entries:
### 2.1 Entity Sensor MIB Extension Scope
-Currently SONiC already have a RFC3433 Entity sensor MIB implementation, Transceiver embeded sensors like temperature, voltage, rx_power, tx_power and tx_bias are alreay included. After Entity MIB was extended as desribed in Section 1, Entity MIB will also be extened to cover more sensors.
-Thermal sensors besides the Transceiver embedded thermal sensors which avalaible in the STATE_DB will all be added to the Entity Sensor MIB support.
+Currently SONiC already have a RFC3433 Entity sensor MIB implementation, Transceiver embedded sensors like temperature, voltage, rx_power, tx_power and tx_bias are already included. After Entity MIB was extended as described in Section 1, Entity MIB will also be extended to cover more sensors.
+Thermal sensors besides the Transceiver embedded thermal sensors which available in the STATE_DB will all be added to the Entity Sensor MIB support.
PSU temperature, voltage, power and current will added, FAN tachometer will be added as well.
### 2.1 Entity Sensor MIB Data Source
diff --git a/doc/snmp/snmp-changes-to-support-ipv6.md b/doc/snmp/snmp-changes-to-support-ipv6.md
index 4e79142de94..5fefeacd7cd 100644
--- a/doc/snmp/snmp-changes-to-support-ipv6.md
+++ b/doc/snmp/snmp-changes-to-support-ipv6.md
@@ -38,7 +38,7 @@ Below is a packet capture showing SNMP request packet sent to DUT Loopback IPV6
2. SNMP request is received at SONiC device is sent to snmpd which is listening on port 161 :::161/
3. snmpd process will parse the request create a response and sent to DST IP fc00::72.
4. snmpd process does not track the DST IP on which the SNMP request was received, which in this case is Loopback IP.
-snmpd process will only keep track what is tht IP to which the response should be sent to.
+snmpd process will only keep track what is that IP to which the response should be sent to.
5. snmpd process will send the response packet.
Kernel will do a route look up on destination IP and find the best path.
ip -6 route get fc00::72
@@ -74,16 +74,16 @@ On multi-asic platform, there exists different network namespaces.
SNMP docker with snmpd process runs on host namespace.
Management interface belongs to host namespace.
Loopback0 is configured on asic namespaces.
-Additional inforamtion on how the packet coming over Loopback IP reaches snmpd process running on host namespace: #5420
+Additional information on how the packet coming over Loopback IP reaches snmpd process running on host namespace: #5420
Because of this separation of network namespaces, the route lookup of destination IP is confined to routing table of specific namespace where packet is received.
If packet is received over management interface, SNMP response also is sent out of management interface. Same goes with packet received over Loopback Ip.
## Changes done to workaround the issue ##
Currently snmpd listens on any ip by default, after this change:
-1. If minigraph.xml is used to load the initial configuration, then SNMP_AGENT_ADDRESS_CONFIG in config_db will be updated with Loopback0 and Managment interface IP addresses during the parsing of minigraph.xml.
+1. If minigraph.xml is used to load the initial configuration, then SNMP_AGENT_ADDRESS_CONFIG in config_db will be updated with Loopback0 and Management interface IP addresses during the parsing of minigraph.xml.
2. No change will be done if config_db.json is used to load the configuration.
-config_db.json file could have SNMP_AGENT_ADDRESS_CONFIG table udpated with required IP addresses for snmpd to listen on.
+config_db.json file could have SNMP_AGENT_ADDRESS_CONFIG table updated with required IP addresses for snmpd to listen on.
Before the change:
snmpd listens on any IP, snmpd binds to IPv4 and IPv6 sockets as below:
@@ -95,7 +95,7 @@ netsnmp_udpbase: binding socket: 8 to UDP/IPv6: [::]:161
When IPv4 response is sent, it goes out of fd 7 and IPv6 response goes out of fd 8.
When IPv6 response is sent, it does not have the right SRC IP and it can lead to the issue described.
-If minigraph.xml is used, then SNMP_AGENT_ADDRESS_CONFIG will be configured with Loopback0 and Managment interface IP addresses. When snmpd listens on specific Loopback/Management IPs, snmpd binds to different sockets:
+If minigraph.xml is used, then SNMP_AGENT_ADDRESS_CONFIG will be configured with Loopback0 and Management interface IP addresses. When snmpd listens on specific Loopback/Management IPs, snmpd binds to different sockets:
```
trace: netsnmp_udpipv4base_transport_bind(): transports/snmpUDPIPv4BaseDomain.c, 207:
netsnmp_udpbase: binding socket: 7 to UDP: [0.0.0.0]:0->[10.250.0.101]:161
@@ -129,7 +129,7 @@ This change is also more secure approach instead of listening over any ip.
### Effects of this change ###
1. If minigraph.xml is used to load the initial configuration, then snmpd will listen on Loopback0/Management IPs on single asic platform.
-2. If config_db.json is used load the configuration, then snmpd will listen on any IP, the IPv6 issue will be seen. To overcome IPv6 issue, SNMP_AGENT_ADDRESS_CONFIG table should be udpated to listen to specific IPv4 or IPv6 addresses using "config snmpagentaddress add ".
+2. If config_db.json is used load the configuration, then snmpd will listen on any IP, the IPv6 issue will be seen. To overcome IPv6 issue, SNMP_AGENT_ADDRESS_CONFIG table should be updated to listen to specific IPv4 or IPv6 addresses using "config snmpagentaddress add ".
3. No change required or done for multi-asic platforms.
### Pull request to support this change ###
diff --git a/doc/snmp/snmp-schema-addition.md b/doc/snmp/snmp-schema-addition.md
index 0c3a60c3018..f1e7884b5d3 100644
--- a/doc/snmp/snmp-schema-addition.md
+++ b/doc/snmp/snmp-schema-addition.md
@@ -5,7 +5,7 @@
Currently SNMP configuration is managed from a mix of yaml files and DB based ACLs, we propose to integrate the SNMP configs into an SNMP table in the DB.
The following document proposes the database Schema in Json format and the list of required changes to the code.
-## Current configurtions for SNMP ##
+## Current configurations for SNMP ##
sonic-buidimage and sonic-snmpagent depend on the following files:
* */etc/sonic/snmp.yaml*
defines 2 keys:
@@ -103,7 +103,7 @@ Where:
New keys:
-* "TYPE": Optional, if ommited defaults to 'RO', there are 2 possible values:
+* "TYPE": Optional, if omitted defaults to 'RO', there are 2 possible values:
* "RO": read-only, the only implemented method at this time.
* "RW": well you never know - here for completeness but unused in the code.
@@ -114,7 +114,7 @@ The changes we propose are only additive to remain compatible with the current i
In repo *sonic-buildimage*:
* *dockers/docker-snmp-v2/snmpd.conf.j2*:
- * verify the existence of the SNMP table in the datatbase and fork behavior if present, if not continue using old method.
+ * verify the existence of the SNMP table in the database and fork behavior if present, if not continue using old method.
* *dockers/docker-snmp-v2/snmpd-config-updater*:
* this file will be deprecated soon by caclmgrd so no updates will be done
diff --git a/doc/snmp/snmp_ciscobgp4mib.md b/doc/snmp/snmp_ciscobgp4mib.md
index 4ef8c345a8d..ef5f711675d 100644
--- a/doc/snmp/snmp_ciscobgp4mib.md
+++ b/doc/snmp/snmp_ciscobgp4mib.md
@@ -3,7 +3,7 @@
This document captures the current implementation design for CiscoBgp4MIB and propose new design change required to support multi-asic platform.
## Current Design
-Snmp docker has two main processes snmpd (master agent), snmp_ax_impl (sub-agent) providing data for some of the MIB tables. Snmp_ax_impl mostly gets data from redis database. For multi-asic platform, changes are made so that snmp_ax_impl connects to all namespace redis databases and provide cumulative result for SNMP query. Currently the data required for CiscoBgp4MIB is retrieved from bgpd deamon. snmp_ax_impl connects to bgpd daemon via tcp socket and retreives the BGP neighbor information required for CiscoBgp4MIB.
+Snmp docker has two main processes snmpd (master agent), snmp_ax_impl (sub-agent) providing data for some of the MIB tables. Snmp_ax_impl mostly gets data from redis database. For multi-asic platform, changes are made so that snmp_ax_impl connects to all namespace redis databases and provide cumulative result for SNMP query. Currently the data required for CiscoBgp4MIB is retrieved from bgpd daemon. snmp_ax_impl connects to bgpd daemon via tcp socket and retrieves the BGP neighbor information required for CiscoBgp4MIB.
Sample output:
```
sonic:/# snmpwalk -v2c -c msft 127.0.0.1 iso.3.6.1.4.1.9.9.187
@@ -13,15 +13,15 @@ iso.3.6.1.4.1.9.9.187.1.2.5.1.3.2.16.252.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 = INTEGER
## Design considerations for multi-asic platform
### Extending current design
-In multi-asic platform, SNMP docker will be running on the host. BGP docker will be running per asic, in corresponding network namespaces. If the currrent design has to be extended, then SNMP docker will have to connect to each BGP via TCP or unix socket. As each BGPd is in a different namespace, BGP docker in each namespace can interact with the snmp_ax_impl in host using docker0 bridge. Docker0 bridge has veth pairs with one interface of the pair on the host and another interface(eth0) inside the namespace. BGPd inside the BGP docker in namespace can open TCP socket to listen on eth0 IP address of the namespace instead of localhost. Snmp_ax_impl can then connect to TCP sockets on each namespace and retrieve data. Another option is to use UNIX socket /var/run/bgpd.vty. For TCP socket, Bgpd in each BGP docker will open socket 240.127.1.x 2065 to talk to VTYSH, currently socket is opened on localhost. If Unix socket is to be used, then /var/run/bgpd.vty of each BGP docker can be used by snmp_ax_impl to get the required data. The issue with this approach is that there will be N number of sockets opened for N asic platform. Also, each BGP docker will have to be updated to use the docker0 IP address network to open the socket.
+In multi-asic platform, SNMP docker will be running on the host. BGP docker will be running per asic, in corresponding network namespaces. If the current design has to be extended, then SNMP docker will have to connect to each BGP via TCP or unix socket. As each BGPd is in a different namespace, BGP docker in each namespace can interact with the snmp_ax_impl in host using docker0 bridge. Docker0 bridge has veth pairs with one interface of the pair on the host and another interface(eth0) inside the namespace. BGPd inside the BGP docker in namespace can open TCP socket to listen on eth0 IP address of the namespace instead of localhost. Snmp_ax_impl can then connect to TCP sockets on each namespace and retrieve data. Another option is to use UNIX socket /var/run/bgpd.vty. For TCP socket, Bgpd in each BGP docker will open socket 240.127.1.x 2065 to talk to VTYSH, currently socket is opened on localhost. If Unix socket is to be used, then /var/run/bgpd.vty of each BGP docker can be used by snmp_ax_impl to get the required data. The issue with this approach is that there will be N number of sockets opened for N asic platform. Also, each BGP docker will have to be updated to use the docker0 IP address network to open the socket.
### New design proposal using STATE_DB
-To avoid multiple-socket approach, the data required by CiscoBgp4MIB can be populated in STATE_DB by a new daemon in BGP docker. This data can be retrieved by snmp_ax_impl from each namespace for multi-asic platform. Current implementaion of CiscoBgp4MIB in SONiC retrives the below information from the device:
+To avoid multiple-socket approach, the data required by CiscoBgp4MIB can be populated in STATE_DB by a new daemon in BGP docker. This data can be retrieved by snmp_ax_impl from each namespace for multi-asic platform. Current implementation of CiscoBgp4MIB in SONiC retrieves the below information from the device:
1. Neighbor IP address
2. Neighbor BGP state
Currently snmp_ax_impl parses the data from Bgpd vtysh to get 'neighbor ip' and 'state'.
-Proposal is to add a new daemon called 'bgpmon' which will populate STATE_DB with the above infomration.
+Proposal is to add a new daemon called 'bgpmon' which will populate STATE_DB with the above information.
Schema:
```
NEIGH_STATE_TABLE {
@@ -37,8 +37,8 @@ This is the new daemon that runs inside of each BGP docker. It will periodicall
In the future, if there are features that require additional neighbor information other then the BGP neighbor IP address and its state, we can raise a new PR to add those new required attributes to the state DB table.
### Changes in SNMP
-snmp_ax_impl will be updated to talk to STATE_DB and retrieve NEIGH_STATE_TABLE. This change will affect both single and multi asic platforms. In case of multi-asic platforms, snmp_ax_impl will retrive data from STATE_DB of all namespaces.
+snmp_ax_impl will be updated to talk to STATE_DB and retrieve NEIGH_STATE_TABLE. This change will affect both single and multi asic platforms. In case of multi-asic platforms, snmp_ax_impl will retrieve data from STATE_DB of all namespaces.
### Future work
-SONiC uses snmpd implementation for Bgp4MIB(1.3.6.1.2.1.15). This implemenation uses bgpd as a subagent for this MIB tree. This implementation cannot be extended for multi-asic platform where multiple bgpd exists. Multiple entries exist within Bgp4MIB and is currently not supported for multi-asic platform. Bgp4MIB In order to support this MIB, bgpmon can be extended in future, to add the required data in STATE_DB which can be retrieved by snmp_ax_impl.
+SONiC uses snmpd implementation for Bgp4MIB(1.3.6.1.2.1.15). This implementation uses bgpd as a subagent for this MIB tree. This implementation cannot be extended for multi-asic platform where multiple bgpd exists. Multiple entries exist within Bgp4MIB and is currently not supported for multi-asic platform. Bgp4MIB In order to support this MIB, bgpmon can be extended in future, to add the required data in STATE_DB which can be retrieved by snmp_ax_impl.
diff --git a/doc/sonic-application-extension/sonic-application-extension-guide.md b/doc/sonic-application-extension/sonic-application-extension-guide.md
index 736f48b6dac..7cca5cbcccd 100644
--- a/doc/sonic-application-extension/sonic-application-extension-guide.md
+++ b/doc/sonic-application-extension/sonic-application-extension-guide.md
@@ -183,20 +183,20 @@ The value should contain a JSON serialized as a string.
| /service/wanted-by | list of strings | no | List of SONiC services that wants for this package.The option maps to systemd's unit "WantedBy=". |
| /service/after | list of strings | no | Boot order dependency. List of SONiC services the application is set to start after on system boot. |
| /service/before | list of strings | no | Boot order dependency. List of SONiC services the application is set to start before on system boot. | |
-| /service/delayed | boolean | no | Wether to generate a timer to delay the service on boot. Defaults to false. |
-| /service/dependent-of | lits of strnigs | no | List of SONiC services this application is dependent of.
Specifying in this option a service X, will regenerate the /usr/local/bin/X.sh script and upgrade the "DEPENDENT" list with this package service.
This option is warm-restart related, a warm-restart of service X will not trigger this package service restart.
On the other hand, this service package will be started, stopped, restarted togather with service X.
Example:
For "dhcp-relay", "radv", "teamd" this field will have "swss" service in the list. |
-| /service/post-start-action | string | no | Path to an executable inside Docker image filesystem to be executed after container start.
A package may use this field in case a systemd service should not reach started state before some condition. E.g.: A database service should not reach started state before redis process is not ready. Since, there is no control, when the redis process will start a "post-start-action" script may execute "redis-cli ping" till the ping is succeessful. |
+| /service/delayed | boolean | no | Whether to generate a timer to delay the service on boot. Defaults to false. |
+| /service/dependent-of | lits of strnigs | no | List of SONiC services this application is dependent of.
Specifying in this option a service X, will regenerate the /usr/local/bin/X.sh script and upgrade the "DEPENDENT" list with this package service.
This option is warm-restart related, a warm-restart of service X will not trigger this package service restart.
On the other hand, this service package will be started, stopped, restarted together with service X.
Example:
For "dhcp-relay", "radv", "teamd" this field will have "swss" service in the list. |
+| /service/post-start-action | string | no | Path to an executable inside Docker image filesystem to be executed after container start.
A package may use this field in case a systemd service should not reach started state before some condition. E.g.: A database service should not reach started state before redis process is not ready. Since, there is no control, when the redis process will start a "post-start-action" script may execute "redis-cli ping" till the ping is successful. |
| /service/pre-shutdown-action | string | no | Path to an executable inside Docker image filesystem to be executed before container stops.
A uses case is to execute a warm-shutdown preparation script.
A script that sends SIGUSR1 to teamd to initiate warm shutdown is one of such examples. |
-| /service/host-service | boolean | no | Multi-ASIC field. Wether a service should run in host namespace. Default is True. |
-| /service/asic-service | boolean | no | Multi-ASIC field. Wether a service should run per ASIC namespace. Default is False. |
+| /service/host-service | boolean | no | Multi-ASIC field. Whether a service should run in host namespace. Default is True. |
+| /service/asic-service | boolean | no | Multi-ASIC field. Whether a service should run per ASIC namespace. Default is False. |
| /service/warm-shutdown/ | object | no | Warm reboot related properties. Used to generate the warm-reboot script. |
| /service/warm-shutdown/after | lits of strings | no | Warm shutdown order dependency. List of SONiC services the application is set to stop after on warm shutdown.
Example: a "bgp" may specify "radv" in this field in order to avoid radv to announce departure and cause hosts to lose default gateway.
*NOTE*: Putting "radv" here, does not mean the "radv" should be installed as there is no such dependency for the "bgp" package. |
| /service/warm-shutdown/before | lits of strings | no | Warm shutdown order dependency. List of SONiC services the application is set to stop before on warm shutdown.
Example: a "teamd" service has to stop before "syncd", but after "swss" to be able to send the last LACP PDU though CPU port right before CPU port becomes unavailable. |
| /service/fast-shutdown/ | object | no | Fast reboot related properties. Used to generate the fast-reboot script. |
| /service/fast-shutdown/after | lits of strings | no | Same as for warm-shutdown. |
| /service/fast-shutdown/before | lits of strings | no | Same as for warm-shutdown. |
-| /processes | object | no | Processes infromation |
-| /processes/[name]/reconciles | boolean | no | Wether process performs warm-boot reconciliation, the warmboot-finalizer service has to wait for. Defaults to False. |
+| /processes | object | no | Processes information |
+| /processes/[name]/reconciles | boolean | no | Whether process performs warm-boot reconciliation, the warmboot-finalizer service has to wait for. Defaults to False. |
| /container | object | no | Container related properties. |
| /container/privileged | string | no | Start the container in privileged mode. Later versions of manifest might extend container properties to include docker capabilities instead of privileged mode. Defaults to False. |
| /container/volumes | list of strings | no | List of mounts for a container. The same syntax used for '-v' parameter for "docker run".
Example: "\:\:\". Defaults to []. |
@@ -208,12 +208,12 @@ The value should contain a JSON serialized as a string.
| /container/environment | dict | no | Environment variables for Docker container (key=value). Defaults to {}. |
| /processes | list | no | A list defining processes running inside the container. |
| /cli | object | no | CLI plugin information. *NOTE*: Later will deprecated and replaced with a YANG module file path. |
-| /cli/mandatory | boolean| no | Wether CLI is a mandatory functionality for the package. Default: False. |
+| /cli/mandatory | boolean| no | Whether CLI is a mandatory functionality for the package. Default: False. |
| /cli/show-cli-plugin | list of strings | no | List of paths to plugins for sonic-utilities show CLI command. |
| /cli/config-cli-plugin | list of strings | no | List of paths to plugins for sonic-utilities config CLI command. |
| /cli/clear-cli-plugin | list of strings | no | List of paths to plugins for sonic-utilities sonic-clear CLI command. |
-| /cli/auto-generate-config | boolean| yes | ON/OFF triger for auto-generation of CLI command *config*. Default: false |
-| /cli/auto-generate-show | boolean| yes | ON/OFF triger for auto-generation of CLI command *show*. Default: false |
+| /cli/auto-generate-config | boolean| yes | ON/OFF trigger for auto-generation of CLI command *config*. Default: false |
+| /cli/auto-generate-show | boolean| yes | ON/OFF trigger for auto-generation of CLI command *show*. Default: false |
| /cli/auto-generate-config-source-yang-modules | list of strings | no | If set, config CLI auto-generation will only apply to specified YANG modules. The YANG module is referenced by the name recorded in labels (which should match the name of the module) |
| /cli/auto-generate-show-source-yang-modules | list of strings | no | If set, config CLI auto-generation will only apply to specified YANG modules. The YANG module is referenced by the name recorded in labels (which should match the name of the module) |
diff --git a/doc/sonic-application-extension/sonic-application-extention-hld.md b/doc/sonic-application-extension/sonic-application-extention-hld.md
index 12f5f4861d7..318351b404b 100644
--- a/doc/sonic-application-extension/sonic-application-extention-hld.md
+++ b/doc/sonic-application-extension/sonic-application-extention-hld.md
@@ -181,7 +181,7 @@ These are Dockers for which it might be complicated to separate the OS part from
Built-in packages **cannot** be *removed* and *upgraded* as SONiC Packages and the infrastructure will mark them with a special built-in flag.
This will allow for a smooth transition of SONiC Docker images into SONiC Packages by marking all of the existing Docker images as
-build-in and then removing this flag for images that become a SONiC Packages.
+built-in and then removing this flag for images that become a SONiC Packages.
The following list enumerates some built-in Docker containers, that cannot become SONiC Package at current stage:
- database
@@ -385,7 +385,7 @@ This way the user can ensure the integrity and the publisher of the image he is
#### CLI Enhancements
The SONiC Package Manager is another executable utility available in base SONiC OS called *sonic-package-manager* or abbreviated to *spm*.
-The command line interfaces are given bellow:
+The command line interfaces are given below:
#### CLI
@@ -458,7 +458,7 @@ Usage: sonic-package-manager install [OPTIONS] [PACKAGE_EXPR]
Options:
-y, --yes Answer yes for any prompt
-f, --force Force installation
- --enable Wether to enable feature after install
+ --enable Whether to enable feature after install
--default-owner [local|kube] Default configured owner
--from-repository Install directly from repository specified
in this options. Format is the same as for
@@ -470,7 +470,7 @@ Options:
--skip-cli-plugin-installation Do not install CLI plugins provided by the
package on the host OS
Note: In case package CLI is defined as mandatory
- and this option is beeing used the installation
+ and this option is being used the installation
will fail.
--help Show this message and exit
```
@@ -763,7 +763,7 @@ For the list of supported expressions check the python library that is going to
SDK refers to [SONiC SDK Docker Images](#sonic-sdk-docker-images).
SDK Docker image records an set of library versions in labels that gets inherited by the package image. This allows to perform an
-automatic compatibility check. If libraries constarints are not defined in the manifest but a library version exists in labels of a package the constraint will initialize for that component as "^$major.$minor.0". E.g:
+automatic compatibility check. If libraries constraints are not defined in the manifest but a library version exists in labels of a package the constraint will initialize for that component as "^$major.$minor.0". E.g:
Package Foo is build with following labels:
@@ -790,7 +790,7 @@ LABEL com.azure.sonic.versions.libsairedis = 1.3.0
libswsscommon is validated against "^1.0.0,^2.0.0", libsairedis is validated using "^1.3.0".
This gives more guaranties to the user that if package installs it is compatible.
-If pacakge does not use sairedis interface, user can put "*" to match any version in Bar.
+If package does not use sairedis interface, user can put "*" to match any version in Bar.
### SONiC Package Changelog
@@ -913,7 +913,7 @@ manifest.
| /service/after | list of strings | no | Boot order dependency. List of SONiC services the application is set to start after on system boot. |
| /service/before | list of strings | no | Boot order dependency. List of SONiC services the application is set to start before on system boot. |
| /service/wanted-by | list of strings | no | Services list that "wants" this service. Maps to systemd's WantedBy |
-| /service/delayed | boolean | no | Wether to generate a timer to delay the service on boot. Defaults to false. |
+| /service/delayed | boolean | no | Whether to generate a timer to delay the service on boot. Defaults to false. |
@@ -929,10 +929,10 @@ before or after a the container ENTRYPOINT is started.
Example of container lifecycle hook can apply to a database package. A database systemd service should not reach started state
before redis process is ready otherwise other services will start but fail to connect to the database. Since, there is no control
-when the redis process starts a *post-start-action* script may execute "sonic-db-cli ping" till the ping is succeessful.
+when the redis process starts a *post-start-action* script may execute "sonic-db-cli ping" till the ping is successful.
This will ensure that service start is blocked till the redis service is up and running.
-The *pre-shutdown-action* might be usefull to execute a specific action to prepare for warm reboot. For example, teamd script that sends
+The *pre-shutdown-action* might be useful to execute a specific action to prepare for warm reboot. For example, teamd script that sends
SIGUSR1 to teamd to initiate warm shutdown. Note, the usage of the pre-shutdown action is not limited to warm restart and is invoked every
time the container is about to be stopped or killed.
@@ -953,12 +953,12 @@ MULTI_INST_DEPENDENT="teamd"
```
```
-DEPDENDENT=$(cat /etc/sonic/${SERVICE}_dependent)
+DEPENDENT=$(cat /etc/sonic/${SERVICE}_dependent)
MULTI_INST_DEPENDENT=$(cat /etc/sonic/${SERVICE}_multi_inst_dependent)
```
The infrastructure is not deciding whether this script is needed for a particular package or not based on warm-reboot requirements or
-container lifetime hooks provided by a feature, instead this script is always generated and if no specific actions descirbed above
+container lifetime hooks provided by a feature, instead this script is always generated and if no specific actions described above
are needed it becomes a simple wrapper around a script under /usr/bin/.
Examples are [swss.sh](https://github.com/sonic-net/sonic-buildimage/blob/master/files/scripts/swss.sh),
@@ -976,8 +976,8 @@ after installation all the service scripts under */usr/local/bin/* are re-genera
| Path | Type | Mandatory | Description |
| ---------------------------- | --------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| /service/dependent-of | lits of strnigs | no | List of SONiC services this application is dependent of.Specifying in this option a service X, will regenerate the /usr/local/bin/X.sh script and upgrade the "DEPENDENT" list with this package service.
This option is warm-restart related, a warm-restart of service X will not trigger this package service restart.
On the other hand, this service package will be started, stopped, restarted togather with service X.
Example:
For "dhcp-relay", "radv", "teamd" this field will have "swss" service in the list. |
-| /service/post-start-action | string | no | Path to an executable inside Docker image filesystem to be executed after container start.
A package may use this field in case a systemd service should not reach started state before some condition. E.g.: A database service should not reach started state before redis process is not ready. Since, there is no control, when the redis process will start a "post-start-action" script may execute "redis-cli ping" till the ping is succeessful. |
+| /service/dependent-of | lits of strnigs | no | List of SONiC services this application is dependent of.
Specifying in this option a service X, will regenerate the /usr/local/bin/X.sh script and upgrade the "DEPENDENT" list with this package service.
This option is warm-restart related, a warm-restart of service X will not trigger this package service restart.
On the other hand, this service package will be started, stopped, restarted together with service X.
Example:
For "dhcp-relay", "radv", "teamd" this field will have "swss" service in the list. |
+| /service/post-start-action | string | no | Path to an executable inside Docker image filesystem to be executed after container start.
A package may use this field in case a systemd service should not reach started state before some condition. E.g.: A database service should not reach started state before redis process is not ready. Since, there is no control, when the redis process will start a "post-start-action" script may execute "redis-cli ping" till the ping is successful. |
| /service/pre-shutdown-action | string | no | Path to an executable inside Docker image filesystem to be executed before container stops.
A uses case is to execute a warm-shutdown preparation script.
A script that sends SIGUSR1 to teamd to initiate warm shutdown is one of such examples. |
@@ -1129,7 +1129,7 @@ ave to be also auto-generated from YANG in the future.
| Path | Type | Mandatory | Description |
| ---------------------- | ------ | --------- | --------------------------------------------------------------- |
-| /cli/mandatory | boolean| no | Wether CLI is a mandatory functionality for the package. Default: False. |
+| /cli/mandatory | boolean| no | Whether CLI is a mandatory functionality for the package. Default: False. |
| /cli/show-cli-plugin | list of strings | no | List of paths to plugins for sonic-utilities show CLI command. |
| /cli/config-cli-plugin | list of strings | no | List of paths to plugins for sonic-utilities config CLI command. |
| /cli/clear-cli-plugin | list of strings | no | List of paths to plugins for sonic-utilities sonic-clear CLI command. |
@@ -1227,8 +1227,8 @@ corresponding service files are created per each namespace. *systemd-sonic-gener
| Path | Value | Mandatory | Description |
| --------------------- | ------- | --------- | ----------------------------------------------------------------------------------- |
-| /service/host-service | boolean | no | Multi-ASIC field. Wether a service should run in host namespace. Default is True. |
-| /service/asic-service | boolean | no | Multi-ASIC field. Wether a service should run per ASIC namespace. Default is False. |
+| /service/host-service | boolean | no | Multi-ASIC field. Whether a service should run in host namespace. Default is True. |
+| /service/asic-service | boolean | no | Multi-ASIC field. Whether a service should run per ASIC namespace. Default is False. |
### Warmboot and Fastboot Design Impact
@@ -1237,7 +1237,7 @@ to announce departure and cause hosts to lose default gateway, while "teamd" ser
send the last LACP PDU though CPU port right before CPU port becomes unavailable.
The warm-reboot and fast-reboot service shutdown scripts have to be auto-generated from a template */usr/share/sonic/templates/fast-shutdown.sh.j2*
-and */usr/share/sonic/templates/warm-shutdown..sh.j2* wich are symbolic links to the same template. The templates are derived from the fast-reboot
+and */usr/share/sonic/templates/warm-shutdown..sh.j2* which are symbolic links to the same template. The templates are derived from the fast-reboot
script from sonic-utlities.
A services shutdown is an ordered executions of *systemctl stop {{ service }}* commands with an exception for "swss" service after which a syncd
@@ -1272,8 +1272,8 @@ systemctl stop {{ service }}
| /service/fast-shutdown/ | object | no | Fast reboot related properties. Used to generate the fast-reboot script. |
| /service/fast-shutdown/after | lits of strings | no | Same as for warm-shutdown. |
| /service/fast-shutdown/before | lits of strings | no | Same as for warm-shutdown. |
-| /processes | object | no | Processes infromation |
-| /processes/[name]/reconciles | boolean | no | Wether process performs warm-boot reconciliation, the warmboot-finalizer service has to wait for. Defaults to False. |
+| /processes | object | no | Processes information |
+| /processes/[name]/reconciles | boolean | no | Whether process performs warm-boot reconciliation, the warmboot-finalizer service has to wait for. Defaults to False. |
@@ -1430,7 +1430,7 @@ The list of packages added to *sonic-sdk-buildenv* in addition to *sonic-sdk*:
The SDK images built should be labeled with metadata about the build to give the user an idea about base OS version
compatibility as well as some core packages version compatibility. Packages like *libswsscommon* and *libsairedis*
-have a relation to database, swss, syncd containers they were built togather with.
+have a relation to database, swss, syncd containers they were built together with.
The SDK components versions are saved into labels:
diff --git a/doc/sonic-application-extension/sonic-versioning-strategy.md b/doc/sonic-application-extension/sonic-versioning-strategy.md
index 1dd60084459..d0394033e30 100644
--- a/doc/sonic-application-extension/sonic-versioning-strategy.md
+++ b/doc/sonic-application-extension/sonic-versioning-strategy.md
@@ -31,9 +31,9 @@ This document provides guidelines on how to do versioning for SONiC Docker Image
#### Motivation
-With new SONiC Application Extension Infrastructure SONiC Dockers and SONiC Base OS can be seperated and distributed individually.
+With new SONiC Application Extension Infrastructure SONiC Dockers and SONiC Base OS can be separated and distributed individually.
SONiC Dockers (aka SONiC Packages) can be installed, upgraded invididually from other. This creates a new problem which needs to be
-solved - compatibility between dependend Dockers and host OS. SONiC Application Extension Infrastructure provides a way to specify
+solved - compatibility between dependent Dockers and host OS. SONiC Application Extension Infrastructure provides a way to specify
the package version dependency using semantic versioning (https://semver.org). This document provides a guideline on how to increment
version numbers correctly on releases.
@@ -84,7 +84,7 @@ BREAKING CHANGE: this feature breaks the Consumer/Producer based IPC
**NOTE**: SONiC package version has no correlation to a SONiC release. While keeping API of dependencies compatible a package can work across different SONiC releases.
-Package maintainer may choose to maintain a single repository and have there packages that can work accross different releases or maintain a repository per SONiC release.
+Package maintainer may choose to maintain a single repository and have there packages that can work across different releases or maintain a repository per SONiC release.
***package maintainer can*** update *default-reference* in package.json in SONiC buildimage to point to a default version which will be used when user installs a package.
@@ -185,7 +185,7 @@ foo's manifest:
5. Dependencies SDK changes
-An infrastructure can detect wether package foo is using SDK componenet major version same as foo's dependencies. This automatic check does not require package maintainer additional manifest configuration.
+An infrastructure can detect whether package foo is using SDK component major version same as foo's dependencies. This automatic check does not require package maintainer additional manifest configuration.
For more control foo developer can specify more exact rules.
diff --git a/doc/sonic-application-extension/tpcm_app_ext.md b/doc/sonic-application-extension/tpcm_app_ext.md
index cf01f80c2cf..0a39b050563 100644
--- a/doc/sonic-application-extension/tpcm_app_ext.md
+++ b/doc/sonic-application-extension/tpcm_app_ext.md
@@ -71,7 +71,7 @@ SONiC is an open and extensible operating system. SONiC can be extended with Thi
- Dynamically install TPCs from various sources without pre-packaging them in SONIC.
- Ensure TPC has right system resources and privileges
-- Abilitiy to configure startup command arguments to TPC
+- Ability to configure startup command arguments to TPC
- Configure resource limits to TPCs, to ensure it does not starve core SONiC containers
- Ability to seamlessly integrate into SONiC Services Architecture enabling start/ auto restart/ establish dependencies
@@ -96,7 +96,7 @@ There is no change to the SONiC architecture.
### High-Level Design
-SONiC Application Extension Infrastructure provides the framework to integrate SONiC compatible dockers. However there are many open source third party applications which can be installed on SONiC system, to extend the capabilities, and these typically are standalone or have less interaction with the SONiC system itself. So it is not necesary to for these docker applications to be SONiC compliant, and provide their corresponding manifest.json. These TPCs can be installed dynamically on a SONiC device and can be managed.
+SONiC Application Extension Infrastructure provides the framework to integrate SONiC compatible dockers. However there are many open source third party applications which can be installed on SONiC system, to extend the capabilities, and these typically are standalone or have less interaction with the SONiC system itself. So it is not necessary to for these docker applications to be SONiC compliant, and provide their corresponding manifest.json. These TPCs can be installed dynamically on a SONiC device and can be managed.
- This feature enables the installation and management of third-party Docker packages without manifest files through the Sonic Package Manager.
- This feature enables users to create a local custom manifest file (from default manifest template file) on-the-fly which can be updated or deleted as needed.
@@ -231,7 +231,7 @@ Not applicable
#### CLI Enhancements
-The SONiC Package Manager is another executable utility available in base SONiC OS called *sonic-package-manager* or abbreviated to *spm*. This would be extended to support these new TPCM capabilities. The command line interfaces are given bellow:
+The SONiC Package Manager is another executable utility available in base SONiC OS called *sonic-package-manager* or abbreviated to *spm*. This would be extended to support these new TPCM capabilities. The command line interfaces are given below:
#### CLI
@@ -385,8 +385,8 @@ TPC with resource limits will be provided in the followup.
### Future Enhancements Proposal
-- Local custom Manfiest file could be used(created/updated) for SONiC packages as well.
-- TPC could be configured to start right after system becomes ready so that SONiC packages bootup wont be delayed.
+- Local custom Manifest file could be used(created/updated) for SONiC packages as well.
+- TPC could be configured to start right after system becomes ready so that SONiC packages bootup won't be delayed.
- Data preservation in TPCM migration
- TPC and SONiC containers to have resource limits in place in config db.
diff --git a/doc/sonic-build-system/SONiC-Reproduceable-Build.md b/doc/sonic-build-system/SONiC-Reproduceable-Build.md
index 0ff8371f936..f70f6f7acb5 100644
--- a/doc/sonic-build-system/SONiC-Reproduceable-Build.md
+++ b/doc/sonic-build-system/SONiC-Reproduceable-Build.md
@@ -391,7 +391,7 @@ The Pypi official mirror supports multiple versions of each binary package. It i
The design of the Pypi package mirror is only for monitoring and alerting. When a specified version of the package is used in SONiC, we can expect the package should never be changed. If it was changed (the same package name and version, but different binary), we will be notified.
-If a package used by SONiC is removed from the Pypi official mirror accidently, the SONiC build will be failed. One of the solution is to add the extra URLs for pip command, see [here](https://pip.pypa.io/en/stable/reference/pip_install/#install-extra-index-url). But the risk should be very low, we keep to update the version to the latest one by design. It should not be the high priority task to do it.
+If a package used by SONiC is removed from the Pypi official mirror accidentally, the SONiC build will be failed. One of the solution is to add the extra URLs for pip command, see [here](https://pip.pypa.io/en/stable/reference/pip_install/#install-extra-index-url). But the risk should be very low, we keep to update the version to the latest one by design. It should not be the high priority task to do it.
To publish only the packages used by SONiC, the used packages and versions should be collected by SONiC build. The input file should be like this as below:
diff --git a/doc/sonic-build-system/build-enhancements.md b/doc/sonic-build-system/build-enhancements.md
index 2bb0b879813..fb054c3603c 100644
--- a/doc/sonic-build-system/build-enhancements.md
+++ b/doc/sonic-build-system/build-enhancements.md
@@ -74,8 +74,8 @@ This feature provides improvements in three essential areas.
- Binary image build optimization
- Use tmpfs and OverlayFS to speed up the build process.
- Build caching
- - Version cache - Package cache support for build componets that are downloaded from external world.
- - Image cache support for installer image componets.
+ - Version cache - Package cache support for build components that are downloaded from external world.
+ - Image cache support for installer image components.
Reference:
- Version caching feature is enhanced on top of DPKG caching and Versioning framework.
@@ -148,34 +148,34 @@ This feature provides build improvements in SONIC.
- Docker-In-Docker mode.
- Installing and running another Docker engine (daemon) inside a Docker container.
- - Since Docker 0.6, a "privileged" option is added to allow running containers in a special mode with almost all capabilities of the host machine, including kernel features and devices acccess.
+ - Since Docker 0.6, a "privileged" option is added to allow running containers in a special mode with almost all capabilities of the host machine, including kernel features and devices access.
- As a consequence, Docker engine, as a privileged application, can run inside a Docker container itself.
- - Docker-in-Docker solution is not recommented, especially in containerized Jenkins systems as potential problems include
+ - Docker-in-Docker solution is not recommended, especially in containerized Jenkins systems as potential problems include
- Security profile of inner Docker will conflict with one of outer Docker
- Incompatible file systems (e.g. AUFS inside Docker container).
- As a workaround to address these problems using:
- Container creation using dind docker solutions.
- To use AUFS in the inner Docker, just promote /var/lib/docker to inner docker.
- - Apar´t from the security aspect, a lot of performace panalities are involved as it uses the UnionFS/OverlayFS that degrades the performace when number of lower layers are more.
+ - Apar´t from the security aspect, a lot of performance panalities are involved as it uses the UnionFS/OverlayFS that degrades the performance when number of lower layers are more.
- All the child container resource usage is restricted within the paraent container usage.
- Native docker mode.
- - The DoD mode uses socket file(/var/run/docker.sock) to communitcate with host dockerd daemon.
+ - The DoD mode uses socket file(/var/run/docker.sock) to communicate with host dockerd daemon.
- It uses the shared socket file between HOST and the container to run the build container.
- Eg: docker run -v /var/run/docker.sock:/var/run/docker.sock ...
- When a new docker container/builder/composer is invoked from a build container:
- - It is started as a sibiling to build container.
+ - It is started as a sibling to build container.
- It will run in parallel with build container.
- This mode provides a better performance as it can utilize the full potential of host machine.
#### Build Container in SONiC:
-- The current SONiC build infrastructure generats all the SONiC build artifacts inside the docker container environment. When docker is isolated from the host CPU, the docker resource usage and filesystem access are restricted from its full capacity. Docker isolation is more essential for application containers, but for the build containers, the more essentail requirement is the build performace rather than adopting a higher security model. It provides the better build performance when the build containers are run in native mode.
+- The current SONiC build infrastructure generates all the SONiC build artifacts inside the docker container environment. When docker is isolated from the host CPU, the docker resource usage and filesystem access are restricted from its full capacity. Docker isolation is more essential for application containers, but for the build containers, the more essential requirement is the build performance rather than adopting a higher security model. It provides the better build performance when the build containers are run in native mode.
- Sonic supports both the mode of build container creation.
-- The Native docker mode gives better performace but it has some limitations:
+- The Native docker mode gives better performance but it has some limitations:
- In a shared build servers, sonic docker creation from multiple user would give conflict as it shares the same docker image name.
- This feature addresses:
- Sonic docker container creation in parallel from multiple users.
- - Since it runs as sibling container, it will provide better container performace.
+ - Since it runs as sibling container, it will provide better container performance.
- As it shares the host dockerd, it gives better performance as the multilevel UNIONFS/OverlayFS is not needed.
#### Build Container in SONiC:
@@ -198,14 +198,14 @@ This feature provides build improvements in SONIC.
- The user tag is created with combination of user name and SHA ID of Docker control files(Dockerfile.j2, etc)
- Different user tag is genenrated for a different branch of the same user.
-- Docker image save sequence protected with lock as bellow,
+- Docker image save sequence protected with lock as below,
- docker_image_lock()
- docker tag docker-name-\:latest docker-name:latest
- docker save docker-name:latest > docker-name-\.gz
- docker rm docker-name:latest
- docker_image_unlock()
-- Docker image load sequence protected with lock as bellow,
+- Docker image load sequence protected with lock as below,
- docker_image_lock()
- docker load -i < docker-name-\.gz
- docker tag docker-name:latest docker-name-\:latest
@@ -219,21 +219,21 @@ This feature provides build improvements in SONIC.
### Target Specific Build Root
- OverlayFS allows multiple virtual rootfs creation for target specific build.
-- Virtual bulid root - Merging the container root(/) and SONiC source(/sonic) and mounted into target specific virutal build root using OverlayFS.
+- Virtual build root - Merging the container root(/) and SONiC source(/sonic) and mounted into target specific virtual build root using OverlayFS.
- Use tmpfs mount for better performance.
- This would avoid the target specific(UNINSTALLS) and improve the parallel build performance.
- \# mkdir -p BUILD
- \# mkdir -p BUILD
- - \# mount -t tmpfs -o size=1G tmpfs BUILD (optional - performace)
+ - \# mount -t tmpfs -o size=1G tmpfs BUILD (optional - performance)
- \# mount -t overlay overlay -olowerdir=/,upperdir=/sonic/,workdir=BUILD/work BUILD/sonic-buildimage/
- \# chroot BUILD/sonic-buildimage/ /bin/bash
- bash# mount -t proc proc /proc
- bash# dpkg -i && make
### Parallel Make
- - Propogate the DEB_BUILD_OPTIONS='--parallel' to all it sub target.
- - Progation of parallel option to python pip install packages through ENV export.
+ - Propagate the DEB_BUILD_OPTIONS='--parallel' to all it sub target.
+ - Propagation of parallel option to python pip install packages through ENV export.
## Version cache support
@@ -248,7 +248,7 @@ This feature provides build improvements in SONIC.
- Go modules
- Other tools and utilities
-- These components are getting updated fequently and the changes are dynamic in nature.
+- These components are getting updated frequently and the changes are dynamic in nature.
- Versioning feature support the sonic build to particular version of the package to be downloaded/installed.
- Versioning ability to select the particular package version, but still it will fetch the package from external world.
- When external site is down, selected package version is not available or any other issues with connecting to external site or downloading the package would lead to sonic build failure.
@@ -366,7 +366,7 @@ files/build/versions/
Example: debian-stetch-sha256-7f2706b124ee835c3bcd7dc81d151d4f5eca3f4306c5af5c73848f5f89f10e0b.tgz
- If present but not available in the cache, then it downloads the image and saves into saves in to cache in gz format.
- - If present and the docker image is availabe in cache, then it preloads the docker image for container preparation.
+ - If present and the docker image is available in cache, then it preloads the docker image for container preparation.
@@ -389,7 +389,7 @@ files/build/versions/
- Makefile
- Common Files
- ENV flags
- - It caches all the go module files as a directory structure instead of compressed tar file as it gives better performace when number of files are more.
+ - It caches all the go module files as a directory structure instead of compressed tar file as it gives better performance when number of files are more.
- Different directory hierarchy is created for each HASH value.
- If HASH matches, it uses rsync to sync the cached modules to GOPATH build directory.
- While storing/retrieving, the cache content is always protected with global lock.
@@ -440,7 +440,7 @@ files/build/versions/
- Docker images that are built and installed from from sonic repo
- Step (1) can be generated as a base image and it can be run in parallel with the other targets, before build image step.
- - Benifits:
+ - Benefits:
- High hit rate, for less dependencies.
- Reduce the cache size.
- Improve the concurrency when cache not hit, the step has small dependencies, can be run with any other steps.
@@ -456,7 +456,7 @@ files/build/versions/
- Version files
- Common makefiles and script utilities.
- Env Flags
- - On the subsequent build, if calculated HASH maches with existing version cache filename, it loads the boostrap files from cache.
+ - On the subsequent build, if calculated HASH matches with existing version cache filename, it loads the bootstrap files from cache.
#### Rootfs preparation
@@ -541,10 +541,10 @@ files/build/versions/
- DPKG_CACHE: Enabled
- VERSION_CACHE: Enabled
- Build Time:
- - 5 Minutes ( Bofore: >40 Minutes )
+ - 5 Minutes ( Before: >40 Minutes )
### BuildiTime Measurement
-| **Feature** | **Normal Build** | **Build Enhacement** |
+| **Feature** | **Normal Build** | **Build Enhancement** |
| --------------------------------- | -------------| -------------------------- |
| DPKG_CACHE=N
VERSION_CACHE=N | \ | \ |
| DPKG_CACHE=Y
VERSION_CACHE=y | \ | \ |
diff --git a/doc/sonic-build-system/build_system_improvements.md b/doc/sonic-build-system/build_system_improvements.md
index 122bdf1d7ea..7de8ffb725b 100644
--- a/doc/sonic-build-system/build_system_improvements.md
+++ b/doc/sonic-build-system/build_system_improvements.md
@@ -153,7 +153,7 @@ If your package can be built in parallel, please either use compat 10 or pass --
- swss-common (can be built in parallel)
- sairedis (~20m -> ~7m)
-## Seperate sairedis RPC from non-RPC build
+## Separate sairedis RPC from non-RPC build
Some work is done on that but no PR (https://github.com/sonic-net/sonic-sairedis/issues/333)
@@ -164,13 +164,13 @@ The idea of improvement is:
- No need to build libthrift, saithrift when 'ENABLE_SYNCD_RPC != y'
- The debian/rules in sairedis is written in a way that it will built sairedis from scratch twice - non-rpc and rpc version.
-This improvement is achivable by specifying in rules/sairedis.mk:
+This improvement is achievable by specifying in rules/sairedis.mk:
```SAIREDIS_DPKG_TARGET = binary-syncd```
-and conditionaly injecting libthrift depending on ENABLE_SYNCD_RPC.
+and conditionally injecting libthrift depending on ENABLE_SYNCD_RPC.
-The overal improvement ~10m.
+The overall improvement ~10m.
sairedis target built time now is ~3m.
diff --git a/doc/sonic-build-system/images/build-enhancements.md b/doc/sonic-build-system/images/build-enhancements.md
index 26fd832068f..749afadfb02 100644
--- a/doc/sonic-build-system/images/build-enhancements.md
+++ b/doc/sonic-build-system/images/build-enhancements.md
@@ -64,7 +64,7 @@ This document describes the Functionality and High level design of the build imp
This feature provides improvements in three essential areas.
- Build container creation using native docker mode.
- - Package cache support for build componets that are downloaded from external world.
+ - Package cache support for build components that are downloaded from external world.
- Image cache support for installer image components.
- Version cache feature is supported on top existing versioning feature.
@@ -130,34 +130,34 @@ This feature provides build improvements in SONIC.
- Docker-In-Docker mode.
- Installing and running another Docker engine (daemon) inside a Docker container.
- - Since Docker 0.6, a “privileged” option is added to allow running containers in a special mode with almost all capabilities of the host machine, including kernel features and devices acccess.
+ - Since Docker 0.6, a “privileged” option is added to allow running containers in a special mode with almost all capabilities of the host machine, including kernel features and devices access.
- As a consequence, Docker engine, as a privileged application, can run inside a Docker container itself.
- - Docker-in-Docker solution is not recommented, especially in containerized Jenkins systems as potential problems include
+ - Docker-in-Docker solution is not recommended, especially in containerized Jenkins systems as potential problems include
- Security profile of inner Docker will conflict with one of outer Docker
- Incompatible file systems (e.g. AUFS inside Docker container).
- As a workaround to address these problems using:
- Container creation using dind docker solutions.
- To use AUFS in the inner Docker, just promote /var/lib/docker to inner docker.
- - Apart from the security aspect, a lot of performace panaliteis are involved as it uses the UnionFS/OverlayFS that degrades the performace when number of lower layers are more.
+ - Apart from the security aspect, a lot of performance panaliteis are involved as it uses the UnionFS/OverlayFS that degrades the performance when number of lower layers are more.
- All the child container resource usage is restricted within the paraent container usage.
- Native docker mode.
- - The DoD mode uses socket file(/var/run/docker.sock) to communitcate with host dockerd daemon.
+ - The DoD mode uses socket file(/var/run/docker.sock) to communicate with host dockerd daemon.
- It uses the shared socket file between HOST and the container to run the build container.
- Eg: docker run -v /var/run/docker.sock:/var/run/docker.sock ...
- When a new docker container/builder/composer is invoked from a build container:
- - It is started as a sibiling to build container.
+ - It is started as a sibling to build container.
- It will run in parallel with build container.
- This mode provides a better performance as it can utilize the full potential of host machine.
### Build Container in SONiC:
-- The current SONiC build infrastructure generats all the SONiC build artifacts inside the docker container environment. When docker is isolated from the host CPU, the docker resource usage and filesystem access are restricted from its full capacity. Docker isolation is more essential for application containers, but for the build containers, the more essentail requirement is the build performace rather than adopting a higher security model. It provides the better build performance when the build containers are run in native mode.
+- The current SONiC build infrastructure generates all the SONiC build artifacts inside the docker container environment. When docker is isolated from the host CPU, the docker resource usage and filesystem access are restricted from its full capacity. Docker isolation is more essential for application containers, but for the build containers, the more essential requirement is the build performance rather than adopting a higher security model. It provides the better build performance when the build containers are run in native mode.
- Sonic supports both the mode of build container creation.
-- The Native docker mode gives better performace but it has some limitations:
+- The Native docker mode gives better performance but it has some limitations:
- In a shared build servers, sonic docker creation from multiple user would give conflict as it shares the same docker image name.
- This feature addresses:
- Sonic docker container creation in parallel from multiple users.
- - Since it runs as sibiling container, it will degrade the parent container performace.
+ - Since it runs as sibling container, it will degrade the parent container performance.
- As it shares the host dockerd, it gives better performance as the multilevel UNIONFS/OverlayFS is not needed.
#### Build Container in SONiC:
@@ -194,7 +194,7 @@ This feature provides build improvements in SONIC.
- Go modules
- Other tools and utilities
-- These components are getting updated fequently and the changes are dynamic in nature.
+- These components are getting updated frequently and the changes are dynamic in nature.
- Versioning feature support the sonic build to particular version of the package to be downloaded/installed.
- Versioning ability to select the particular package version, but still it will fetch the package from external world.
- When external site is down, selected package version is not available or any other issues with connecting to external site or downloading the package would lead to sonic build failure.
@@ -308,7 +308,7 @@ files/build/versions/
Example: debian-stetch-sha256-7f2706b124ee835c3bcd7dc81d151d4f5eca3f4306c5af5c73848f5f89f10e0b.tgz
- If present but not available in the cache, then it downloads the image and saves into saves in to cache in gz format.
- - If present and the docker image is availabe in cache, then it preloads the docker image for container preparation.
+ - If present and the docker image is available in cache, then it preloads the docker image for container preparation.
@@ -331,7 +331,7 @@ files/build/versions/
- Makefile
- Common Files
- ENV flags
- - It caches all the go module files as a directory structure instead of compressed tar file as it gives better performace when number of files are more.
+ - It caches all the go module files as a directory structure instead of compressed tar file as it gives better performance when number of files are more.
- Different directory hierarchy is created for each HASH value.
- If HASH matches, it uses rsync to sync the cached modules to GOPATH build directory.
- While storing/retrieving, the cache content is always protected with global lock.
@@ -379,7 +379,7 @@ files/build/versions/
- Version files
- Common makefiles and script utilities.
- Env Flags
- - On the subsequent build, if calculated HASH maches with existing version cache filename, it loads the boostrap files from cache.
+ - On the subsequent build, if calculated HASH matches with existing version cache filename, it loads the bootstrap files from cache.
#### Rootfs preparation
@@ -453,7 +453,7 @@ files/build/versions/
## Build Time Compression
-| **Feature** | **Normal Build** | **Build Enhacement** |
+| **Feature** | **Normal Build** | **Build Enhancement** |
| --------------------------------- | -------------| -------------------------- |
| DPKG_CACHE=N
VERSION_CACHE=N | \ | \ |
| DPKG_CACHE=Y
VERSION_CACHE=y | \ | \ |
diff --git a/doc/sonic-build-system/saiversioncheck.md b/doc/sonic-build-system/saiversioncheck.md
index 67f077b018c..b5559fe1487 100644
--- a/doc/sonic-build-system/saiversioncheck.md
+++ b/doc/sonic-build-system/saiversioncheck.md
@@ -1,8 +1,8 @@
# SAI API version check
-## Motiviation
+## Motivation
-SONiC is not desing to work in backward compatibility with older vendor SAI implementations.
+SONiC is not design to work in backward compatibility with older vendor SAI implementations.
SAI headers that SONiC's synd daemon is compiled against are taken from OCP SAI repository while
the actual libsai.so is taken from sonic-buildimage vendor's directory. This leads to a situation
that sometimes SAI in sonic-sairedis repository is updated but vendor SAI in sonic-buildimage is not.
@@ -79,6 +79,6 @@ Using that new API we can implement a configure-time check in sonic-sairedis wit
The check will compare the vendor SAI API version (on the left on the Figure 1) with sairedis SAI API version (on the right on the Figure 2.) and fail if they do not match.
-In case, SAI versioning follows sematical versioning rules, the test program can implement a check for only MAJOR and MINOR version, relaxing the constraint on the PATCH version.
+In case, SAI versioning follows semantical versioning rules, the test program can implement a check for only MAJOR and MINOR version, relaxing the constraint on the PATCH version.
## Questions
diff --git a/doc/sonic-multi-architecture/sonic_arm_support.md b/doc/sonic-multi-architecture/sonic_arm_support.md
index 4e133e845bd..c565e92d7b6 100644
--- a/doc/sonic-multi-architecture/sonic_arm_support.md
+++ b/doc/sonic-multi-architecture/sonic_arm_support.md
@@ -165,7 +165,7 @@ Update target platform for Onie image platform configuration in onie image conf.
- onie-image.conf for AMD64
- onie-image-armhf.conf for ARMHF
- onie-image-arm64.conf for ARM64
-Onie platform config file will chosed based on the target platform
+Onie platform config file will chose based on the target platform
- platform//platform.conf
platform.conf will be used by the onie installer script to install the onie image
Onie Installer scripts
@@ -209,14 +209,14 @@ This can be addressed in platform specific makefiles.
### Usage for ARM Architecture
-To build Arm32 bit for (ARMHF) plaform
+To build Arm32 bit for (ARMHF) platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] SONIC_ARCH=armhf
**example**:
make configure PLATFORM=marvell-armhf SONIC_ARCH=armhf
-To build Arm64 bit for plaform
+To build Arm64 bit for platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] SONIC_ARCH=arm64
diff --git a/doc/sonic-port-name.md b/doc/sonic-port-name.md
index d52e8cd7c00..6d602d07f27 100644
--- a/doc/sonic-port-name.md
+++ b/doc/sonic-port-name.md
@@ -2,7 +2,7 @@
## Scope of the change ##
-- Micorsoft proposes to change SONiC port naming convention to [Linux Network Interface Naming](http://tdt.rocks/linux_network_interface_naming.html)
+- Microsoft proposes to change SONiC port naming convention to [Linux Network Interface Naming](http://tdt.rocks/linux_network_interface_naming.html)
## Current SONiC port naming convention ##
- Ethernet[0..(N-1)] where N=32 or 64
diff --git a/doc/srv6/srv6_hld.md b/doc/srv6/srv6_hld.md
index 183df03e455..a5ec2eaaa77 100644
--- a/doc/srv6/srv6_hld.md
+++ b/doc/srv6/srv6_hld.md
@@ -9,7 +9,7 @@
- [1 Introuduction and Scope](#1-introuduction-and-scope)
- [2 Feature Requirements](#2-feature-requirements)
- [2.1 Functional Requirements](#21-functional-requirements)
-- [2.2 Configuration and Managment Requirements](#22-configuration-and-management-requirements)
+- [2.2 Configuration and Management Requirements](#22-configuration-and-management-requirements)
- [2.3 Warm Boot Requirements](#23-warm-boot-requirements)
- [3 Feature Design](#3-feature-design)
- [3.1 ConfigDB Changes](#31-configdb-changes)
@@ -408,9 +408,9 @@ In Srv6Orch, it will mark which route entry is Srv6 modified and having higher p
**Resolve SID NextHop Via Controller or Others:**
-If the SID subnet (below example, 2000::31 on E31) is directly connected to E11, the nexthop could be found, if not, we should have a controller to indicate nexthop information on E11 for subnet 2000::31, since FRR is not involved at this moment on Phase #1. A static route should be installed via controller in APPL_DB ROUTE_TABLE. Or the network itself has some basic ipv6 protocol is ruuning, and all the basic ipv6 informaion is fully exchanged, it depends on how the architecture is designed.
+If the SID subnet (below example, 2000::31 on E31) is directly connected to E11, the nexthop could be found, if not, we should have a controller to indicate nexthop information on E11 for subnet 2000::31, since FRR is not involved at this moment on Phase #1. A static route should be installed via controller in APPL_DB ROUTE_TABLE. Or the network itself has some basic ipv6 protocol is ruuning, and all the basic ipv6 information is fully exchanged, it depends on how the architecture is designed.
-Beside adding/modifing routes, controller could delete routes. When controller deletes some routes, then the higher priority flag will be removed and the routes will be deleted. Frr or other modules could modify the routes the same way as we did today when the srv6 high priority flag doesn't exist.
+Beside adding/modifying routes, controller could delete routes. When controller deletes some routes, then the higher priority flag will be removed and the routes will be deleted. Frr or other modules could modify the routes the same way as we did today when the srv6 high priority flag doesn't exist.
**An Example as below:**
@@ -443,7 +443,7 @@ Orchagent listens to SRV6_MY_SID_TABLE in APP_DB to create SAI objects in ASIC_D
The MySID counters are implemented utilizing the existing Flex Counter infrastructure.
-The FlexCounterManager is extened with a new group - `SRV6_STAT_COUNTER_FLEX_COUNTER_GROUP`. The default polling interval is set to 10 seconds.
+The FlexCounterManager is extended with a new group - `SRV6_STAT_COUNTER_FLEX_COUNTER_GROUP`. The default polling interval is set to 10 seconds.
For MySID counters, SRV6Orchagent:
1. Checks if platform supports SRv6 MySID counter via querying SAI_MY_SID_ENTRY_ATTR_COUNTER_ID attribute capabilities
diff --git a/doc/srv6/srv6_static_config_hld.md b/doc/srv6/srv6_static_config_hld.md
index 4bef37da867..ea49383d951 100644
--- a/doc/srv6/srv6_static_config_hld.md
+++ b/doc/srv6/srv6_static_config_hld.md
@@ -8,7 +8,7 @@
- [1 Introuduction and Scope](#1-introuduction-and-scope)
- [2 Feature Requirements](#2-feature-requirements)
- [2.1 Functional Requirements](#21-functional-requirements)
-- [2.2 Configuration and Managment Requirements](#22-configuration-and-management-requirements)
+- [2.2 Configuration and Management Requirements](#22-configuration-and-management-requirements)
- [2.3 Warm Boot Requirements](#23-warm-boot-requirements)
- [3 Feature Design](#3-feature-design)
- [3.1 New Table in ConfigDB](#31-new-table-in-configdb)
@@ -46,7 +46,7 @@ This document provides general information about the design of the enhancements
# 1 Introuduction and Scope
This document describes the high-level design of the new features in SONiC to support SRv6 SDN.
-The new features include the addtion of a new table in CONFIG_DB to enable configuration of SRv6 and the enhancement of bgpcfgd to program FRR with input from CONFIG_DB.
+The new features include the addition of a new table in CONFIG_DB to enable configuration of SRv6 and the enhancement of bgpcfgd to program FRR with input from CONFIG_DB.
Besides, this document also define new YANG model specification and unit-test cases used to validate the aforementioned features.
Note: frrcfgd in SONiC is also able to program SRv6 configurations to FRR but it is designed for scenarios where BGP is used to propagate SRv6 SIDs. SONiC users can choose either bgpcfgd or frrcfgd to program FRR configurations according to their own use cases freely.
@@ -74,7 +74,7 @@ Warm reboot is intended to be supported for planned system warm reboot.
At the time of writing this document, FRR has been able to program the SRv6 related tables in APPL_DB through fpmsyncd.
However, there is still one gap preventing SONiC being utilized for SRv6 SDN deployment.
-Specifically, there is no mechamism in SONiC allowing SDN controllers or users to directly add configuration for SRv6 without involving BGP.
+Specifically, there is no mechanism in SONiC allowing SDN controllers or users to directly add configuration for SRv6 without involving BGP.
In this document, we define two new tables in CONFIG_DB, i.e. **SRV6_MY_LOCATORS** and **SRV6_MY_SIDS**, which serves as the configuration source of SRv6 in SONiC.
Then, we design a new SRv6 Manager module in bgpcfgd to subscribe to the two tables and compile changes in CONFIG_DB to changes in the configurations of FRR (Note: the new SRv6 Manager relies on the new configuration CLI brought in by [FRR PR#16894](https://github.com/FRRouting/frr/pull/16894)).
diff --git a/doc/srv6/srv6_vpn.md b/doc/srv6/srv6_vpn.md
index c79f0a16035..d16cea3ea2c 100644
--- a/doc/srv6/srv6_vpn.md
+++ b/doc/srv6/srv6_vpn.md
@@ -2,7 +2,7 @@
# Overview
-Alibaba is deploying SRv6 VPN with SONiC based white box router at its edge of the network. The Alibaba's SRv6 VPN use case has been described in muliple conferences. The basic idea follows RFC 8986, which we use SRv6 as a network programming framework for applications. VPN information is used as service anchor points for identifying service instances in the service plane. SRv6 policy could be used to provide paths to let applications reach service instances. The following diagram provides a summary on what Alibaba would like to achieve via SRv6 VPN.
+Alibaba is deploying SRv6 VPN with SONiC based white box router at its edge of the network. The Alibaba's SRv6 VPN use case has been described in multiple conferences. The basic idea follows RFC 8986, which we use SRv6 as a network programming framework for applications. VPN information is used as service anchor points for identifying service instances in the service plane. SRv6 policy could be used to provide paths to let applications reach service instances. The following diagram provides a summary on what Alibaba would like to achieve via SRv6 VPN.
@@ -25,7 +25,7 @@ Besides recent FRR changes for SRv6 VPN contributed by Cisco team, Al
4. SRv6 Policy handling
-FRR changes would be commited to FRR community. SONiC 202305 release would pull in the corresponding version of FRR release.
+FRR changes would be committed to FRR community. SONiC 202305 release would pull in the corresponding version of FRR release.
The minimal FRR version for SRv6 VPN is 8.4, which you could get SRv6 VPN PoC functionalities. FRR version 8.5 or 9.0 would provide Alibaba deployment feature parity.
@@ -174,7 +174,7 @@ The SBFD\_PEER schema is shown as the following
## BFD state change events handling
-When BFD orch receives a BFD session state notification from hardware, BFD orch updates the state information in state db. Other SONiC modules could subscribe the BFD session notification based on their needs. bfdd also needs to be informed. But bfdd belongs to FRR code base, currently, there is no infrastructure to let SONiC generated states be propogated to FRR related processes. Therefore, we take a workaround approach which is described in "Notify BFD state change events to FRR bfdd" section.
+When BFD orch receives a BFD session state notification from hardware, BFD orch updates the state information in state db. Other SONiC modules could subscribe the BFD session notification based on their needs. bfdd also needs to be informed. But bfdd belongs to FRR code base, currently, there is no infrastructure to let SONiC generated states be propagated to FRR related processes. Therefore, we take a workaround approach which is described in "Notify BFD state change events to FRR bfdd" section.
### BFD\_HW STATE in STATE\_DB
@@ -253,7 +253,7 @@ The following schema is added for describing bfd\_hw\_state in STATE\_D
# References
-RFC 8986 Segment Routing over IPv6 (SRv6) Network Programmin
+RFC 8986 Segment Routing over IPv6 (SRv6) Network Programming
RFC 9256 Segment Routing Policy Architecture
@@ -263,7 +263,7 @@ RFC 7881Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IP
# Current SONiC's Design Limitations and workarounds
-We don't have an efficient infrastructure to communicate between FRR related processes and SONiC related processes due to current SONiC design limitation. This area needs to be redesigned in the future. Alibaba's business can't wait for the community agreed solution to be ready, therefore we put in the following workaround for an overall solution in the cloud environment. These workarounds would NOT be commited in 202305 release. We will raise PRs and provide diff for referencing purposes only.
+We don't have an efficient infrastructure to communicate between FRR related processes and SONiC related processes due to current SONiC design limitation. This area needs to be redesigned in the future. Alibaba's business can't wait for the community agreed solution to be ready, therefore we put in the following workaround for an overall solution in the cloud environment. These workarounds would NOT be committed in 202305 release. We will raise PRs and provide diff for referencing purposes only.
## SRv6 policy download
diff --git a/doc/ssh_config/ssh_config.md b/doc/ssh_config/ssh_config.md
index 49ac6f8294e..e5bfc5866c8 100644
--- a/doc/ssh_config/ssh_config.md
+++ b/doc/ssh_config/ssh_config.md
@@ -51,7 +51,7 @@ We want to allow configuring ssh server global settings. This will feature will
### 1.5. Requirements
-This feature requires a dedicated table in the configuration DB, and enhancements of hostcfg demon, in order to allow modifing the relvant ssh configuration files. In order to override ssh configurations, we need to have write access to ssh config files such as /etc/ssh/sshd_config
+This feature requires a dedicated table in the configuration DB, and enhancements of hostcfg demon, in order to allow modifying the relevant ssh configuration files. In order to override ssh configurations, we need to have write access to ssh config files such as /etc/ssh/sshd_config
### 1.6. Architecture Design
#### 1.6.1. Configuration modules
@@ -64,7 +64,7 @@ We want to enhance configDB to include table for ssh server global configuration
We want to enable global ssh server configuration in SONIC. In order to do so will touch few areas in the system:
1. configDB - to include a dedicated table for configurations
2. hostcfg demon - to update ssh config files once configDB relevant areas are modified (and for this feature, ssh server config table)
-3. OS ssh config files - specific for this stage we are only /etc/ssh/sshd_config is going to be modifed by the hostcfg demon.
+3. OS ssh config files - specific for this stage we are only /etc/ssh/sshd_config is going to be modified by the hostcfg demon.
4. OS ssh service - to be restarted after each configuration change.
Note:
@@ -73,10 +73,10 @@ The Daemon is running in the host (without container) that matches this feature,
##### Flow diagram
#### 1.7.1 Flow description
-When the feature is enabled, by modifying the DB manually, user will set ssh server policies/configuration (see options below) by modifing CONFIG_DB in SSH_SERVER_TABLE.
+When the feature is enabled, by modifying the DB manually, user will set ssh server policies/configuration (see options below) by modifying CONFIG_DB in SSH_SERVER_TABLE.
The hostcfgd daemon will be extended to listen to ssh policies/configurations from SSH_SERVER table, parse the inputs and set the new policies to ssh config files, and update ssh server afterwards. Inactivity timeout configured by already existing flows in hostcfgd.
-Updated .j2 config file for max sessions cofiguration:
+Updated .j2 config file for max sessions configuration:
```
# limits.conf.j2
{% if max_sessions -%}
diff --git a/doc/static-route/SONiC_static_route_bfd_hld.md b/doc/static-route/SONiC_static_route_bfd_hld.md
index dfd06f1590d..7d59349ae37 100644
--- a/doc/static-route/SONiC_static_route_bfd_hld.md
+++ b/doc/static-route/SONiC_static_route_bfd_hld.md
@@ -194,7 +194,7 @@ A few examples for the cases that adding/deleting static route, and also differe
1. when static route prefix2 ("bfd"="true") is added to config_db STATIC_ROUTE_TABLE, StaticRouteBfd creates an entry in TABLE_CONFIG, include all the information for this static route
2. StaticRouteBfd also creates an entry in TABLE_SRT, includes all the information in this static route but nexthop list is empty.
-3. For each nexthop in the nexthop list, nh_a and nh_b, because they are alerady in the TABLE_NEXTHOP, StaticRouteBfd add prefix2 to nh_a and nh_b's prefix list, don't need to create BFD sessions because they were created when add prefix1
+3. For each nexthop in the nexthop list, nh_a and nh_b, because they are already in the TABLE_NEXTHOP, StaticRouteBfd add prefix2 to nh_a and nh_b's prefix list, don't need to create BFD sessions because they were created when add prefix1
@@ -328,7 +328,7 @@ Description:
|remove static route A and B|clear static route for next tests|1, route A and B are removed.
2, BFD sessions for the nexthops are removed|
-## StaticRouteBfd retart/crash testing (crash/restart StaticRouteBfd process)
+## StaticRouteBfd restart/crash testing (crash/restart StaticRouteBfd process)
Verify StaticRouteBfd restore information from redis DB and rebuild its internal data struct and continue to handle config or state change.
diff --git a/doc/static-route/SONiC_static_route_hdl.md b/doc/static-route/SONiC_static_route_hdl.md
index 6b186e440a1..4304c7bdc9e 100644
--- a/doc/static-route/SONiC_static_route_hdl.md
+++ b/doc/static-route/SONiC_static_route_hdl.md
@@ -1,490 +1,490 @@
-# Static IP route Configuration
-
-Implement Static IP route Configuration via CLI/REST/gNMI in SONiC management framework for non-management routes.
-
-# High Level Design Document
-#### Rev 0.4
-
-# Table of Contents
- * [List of Tables](#list-of-tables)
- * [Revision](#revision)
- * [About This Manual](#about-this-manual)
- * [Scope](#scope)
- * [Definition/Abbreviation](#definitionabbreviation)
-
-# List of Tables
-[Table 1: Abbreviations](#table-1-abbreviations)
-
-# Revision
-| Rev | Date | Author | Change Description |
-|:---:|:-----------:|:---------------------------:|-----------------------------------|
-| 0.1 | 03/18/2020 | Sucheta Mahara | initial draft |
-| 0.2| 03/20/2020 | Venkatesan Mahalingam | draft |
-| 0.3 | 03/23/2020 | Zhenhong Zhao | FRR Config Support |
-| 0.4 | 04/13/2021 | Sucheta Mahara & Venkatesan Mahalingam | Addressed community review comments |
-
-# About this Manual
-This document provides general information about configuring static routes via Management CLI/REST/gNMI in Sonic.
-# Scope
-Covers general design for supporting static routes in SONiC Management framework.
-
-# Definition/Abbreviation
-
-### Table 1: Abbreviations
-| **Term** | **Meaning** |
-|--------------------------|-------------------------------------|
-| IP | Internet Protocol |
-| VRF | Virtual routing and forwarding
-
-
-# 1 Feature Overview
-
-The documents covers the various interfaces for configuring static routes using SONiC management framework.
-
-## 1.1 Requirements
-
-### 1.1.1 Functional Requirements
-
-Provide ability to configure IPv4 and IPv6 static routes using SONiC management framework.
-
-### 1.1.2 Configuration and Management Requirements
- - Implement Static ip route CLI Commands.
- - REST set/get support for Static IPv4 and IPv6 routes.
- - gNMI set/get support for Static IPv4 and IPv6 routes.
-
-### 1.1.3 Warm Boot Requirements
-With static routes configured, system will be able to do warmboot.
-
-# 2 Functionality
-## 2.1 Target Deployment Use Cases
-Use of sonic management framework to configure routes.
-## 2.2 Functional Description
-Provide CLI, gNMI and REST support for static route configuration.
-
-# 3 Design
-## 3.1 Overview
-An existing table STATIC_ROUTE (which is not used currently) will be used to write static route from the transformer for any CLI, rest or gNMI request. This table will be monitored by frrcfgd daemon and the config will be sent to vtysh shell for configuring in FRR.
-
-
-## 3.2 DB Changes
-### 3.2.1 CONFIG DB
-STATIC_ROUTE table in config DB will be used to support this feature.
-
-#### 3.2.1.1 STATIC_ROUTE
-```JSON
-;Defines IP static route table
-;
-;Status: stable
-
-key = STATIC_ROUTE|vrf-name|prefix ;
-vrf-name = 1\*15VCHAR ; VRF name
-prefix = IPv4Prefix / IPv6prefix
-nexthop = string; List of gateway addresses;
-ifname = string; List of interfaces
-distance = string; {0..255};List of distances.
- Its a Metric used to specify preference of next-hop
- if this distance is not set, default value 0 will be set when this field is not configured for nexthop(s)
-nexthop-vrf = string; list of next-hop VRFs. It should be set only if ifname or nexthop IP is not
- in the current VRF . The value is set to VRF name
- to which the interface or nexthop IP belongs for route leaks.
-blackhole = string; List of boolean; true if the next-hop route is blackholed.
- Default value false will be set when this field is not configured for nexthop(s)
-```
-The nexthop-vrf if set, will allow to create a leaked route in the current VRF(vrf-name). The vrf-name, nexthop-vrf, prefix, ifname, distance and blackhole are all parameters required to configure static routes and route leaks in vtysh.
-If an interface is moved from one VRF to another and it exist in the STATIC_ROUTE table, the configured routes with that interface will become inactive. These routes are stored in vtysh "running config" and STATIC_ROUTE table. It is up to the user to remove stale/inactive routes. They will become active if/when the interface is bound again to the orignal VRF.
-
-In this table each entry based on the index in the lists of nexthop, ifname, distance, nexthop-vrf and blackhole is a set. Together based on the index they specify one next-hop entry as there can be multiple next-hops for a prefix. Empty string and default values will be used to complete the set if required. Prefix and nexthop in a set is expected to have same address family.
-
-In the example -1 table below (0.0.0.0, Ethernet0, 10, default, false) , (2.2.2.1, "", 0,"", false), (0.0.0.0, Ethernet12, 30, Vrf-GREEN, false) are the 3 sets defined for 3 configured next-hops for prefix 10.11.1.0/24 in Vrf-RED.
-In example -2 the blackhole is true for second index and only distance is relevant in blackholed route. Due to blackhole entry (with metric 40) all packets matching 10.12.11.0/24 will be discarded if other specified nexthop is inactive.
-
-```JSON
-Example -1 :--
-
-key = STATIC_ROUTE|Vrf-RED|10.11.1.0/24;
-nexthop = 0.0.0.0, 2.2.2.1, 0.0.0.0
-ifname = Ethernet0,"" , Ethernet12
-distance = 10,0,30
-nexthop-vrf = default,"",Vrf-GREEN
-
-Note:
- Field "blackhole or distance" need not be specified if it has all default values for the sets. False for blackhole and 0 for distance.
- Field "nexthop or ifname or nexthop-vrf need not be specified if they have empty value in all the sets"
-
-EXAMPLE 2:-
-key = STATIC_ROUTE|default|10.12.11.0/24;
-nexthop = 2.2.2.3,""
-distance = 10,40
-blackhole = false, true
-
-
-```
-
-
-Note: This model is proposed in line with ROUTE_TABLE model in application DB used for route updates and "vrf hld" description of STATIC_ROUTE table (which is currently not in use). Some default values like 0.0.0.0 and empty strings are used to complete a set. See the CLI example later to see how the table is filled up step-by-step.
-
-
-### 3.2.2 APP DB
-A table "NEIGH_RESOLVE_TABLE" in application DB will be used to write unresolved next-hop for static routes. This table will be written by router/neighbor module of orchagent and consumed by nbrmgrd process.
-
-## 3.3 Switch State Service Design
-### 3.3.1 Orchestration Agent
-Refer to section 3.2.2
-## 3.4 SyncD
-No change
-## 3.5 SAI
-No change
-## 3.6 User Interface
-### 3.6.1 Data Models
-
-The following open config YANG model will be used to implement this feature.
-
- 1) openconfig-network-instance.yang
- 2) openconfig-local-routing.yang
-openconfig-local-routing-ext.yang will be used to specify unsupported fields and extensions.
-
-Supported YANG containers:-
-```diff
-module: openconfig-network-instance
- +--rw network-instances
- +--rw network-instance* [name]
- +--rw protocols
- +--rw protocol* [identifier name]
- +--rw identifier -> ../config/identifier
- +--rw name -> ../config/name
- +--rw static-routes
- +--rw static* [prefix]
- +--rw prefix -> ../config/prefix
- +--rw config
- | +--rw prefix? inet:ip-prefix
- +--ro state
- | +--ro prefix? inet:ip-prefix
- +--rw next-hops
- +--rw next-hop* [index]
- +--rw index -> ../config/index ----(Read note below)
- +--rw config
- | +--rw index? string
- | +--rw next-hop? union
- | +--rw metric? uint32
- | +--rw oc-local-routing-ext:nexthop-vrf-name? string
- | +--rw oc-local-routing-ext:blackhole? boolean
- +--ro state
- | +--ro index? string
- | +--ro next-hop? union
- | +--ro metric? uint32
- | +--rw oc-local-routing-ext:nexthop-vrf-name? string
- | +--rw oc-local-routing-ext:blackhole? boolean
- +--rw interface-ref
- | +--rw config
- | | +--rw interface? -> /oc-if:interfaces/interface/name
- | +--ro state
- | +--ro interface? -> /oc-if:interfaces/interface/name
-
-
-
-```
-New Parameters
-
-| Keyword | Description |
-|:-----------------:|:-----------:|
-oc-local-routing-ext:nexthop-vrf-name|Specify the nexthop-vrf incase interface or next-hop is not in current instance(i.e VRF). This parameter is explicitly required by vtysh to correctly install route leaks.
-oc-local-routing-ext:blackhole | If set to true the nexhop is a blackholed route. Only metric is relevant when configuring blackhole next-hop for a prefix.
-
-Note: Each next-hop entry has a key called "index" in openconfig yang as shown above. This key is used to uniquely identify a entry in the list of next-hops. This key will be formed based on "interface (interface name if present) + next-hop (next-hop-ip if present) + next-hop vrf-name(if present)" and is expected to be provided correctly by the user for non-blackhole routes. For blackhole route DROP will be used as key. Either interface name or next-hop-ip or both or blackhole should be present for any route to be accessed. i.e Ethernet0_2.2.2.2_default, 3.3.3.3_Vrf-RED, DROP. This key will not be stored in config DB.
-
-
-A new sonic-static-route.yang is defined to store entries in STATIC_ROUTE table in configDB.
-
-```diff
-
-module: sonic-static-route
- +--rw sonic-static-route
- +--rw STATIC_ROUTE
- +--rw STATIC_ROUTE_LIST* [vrf-name prefix]
- +--rw vrf-name union
- +--rw prefix inet:ip-prefix
- +--rw nexthop string
- +--rw ifname string
- +--rw distance string
- +--rw nexthop-vrf string
- +--rw blackhole string
-
-
-```
-
-### 3.6.2 CLI
-#### 3.6.2.1 Configuration Commands
-#### 3.6.2.2 ipv4/ipv6 route config commands
-ip route command is used to configure IPv4 static routes in SONiC.
-ipv6 route command is used to configure IPv6 static routes in SONiC.
-##### 3.6.2.2.1 Syntax
-
-Vrf (for default instance) and distance metric are optional in the CLI.
-
-```
-ip route [vrf ] {[interface ] | [] | [ interface ] | [blackhole]} [nexthop-vrf ] []
-```
-
-```
-ipv6 route [vrf ] {[interface ] | [] | [ interface ] | [blackhole]} [nexthop-vrf ] []
-
-```
-
-
-Syntax Description:
-
-| Keyword | Description |
-|:-----------------:|:-----------:|
-| vrf | The static routes will be configured in the specified VRF. If not specified, default VRF will be used.
-| prefix | This is the destination prefix for IPv4 or IPv6 routes.
-| interface | Specifies the interface to be used for this route. Specify nexthop-vrf correctly if interface is in another VRF.
-| next-hop-ip | This provides the gateway IP for the prefix. Specify nexthop-vrf correctly if this IP is in another VRF.
-| distance Metric| Specifies distance value for this route. Value from 1 to 255.
-|nexthop-vrf| Specifies nexthop-vrf if interface or next-hop-ip is in another VRF.
-|blackhole| Specifies if this nexthop is to be blackholed. Only distance metric is relevant for blackhole.
-
-
-Example:
-
-#### IPv4 examples
-````
-sonic(config)# ip route 10.1.1.1/24 10.1.1.3
-
-In configDB new STATIC_ROUTE table will be filled with following entries for default VRF and prefix:-
-
-key = STATIC_ROUTE|default|10.1.1.1/24;
-nexthop = 10.1.1.3
-
-sonic(config)# ip route 10.1.1.1/24 Ethernet 12 nexthop-vrf Vrf-RED 20
-
-Assumption is Ethernet12 is bound to Vrf-RED.
-STATIC_ROUTE table entries are updated for newly added route:-
-
-key = STATIC_ROUTE|default|10.1.1.1/24;
-nexthop = 10.1.1.3, 0.0.0.0
-ifname = "", Ethernet12
-distance = 0, 20
-nexthop-vrf = "", Vrf-RED
-
-
-sonic(config)# ip route vrf Vrf-RED 10.5.6.6/24 10.5.6.1 nexthop-vrf default 10
-
-Assumption is 10.5.6.1 is in default VRF.
-A new STATIC_ROUTE table will be filled with following entries for Vrf-RED and prefix:-
-
-key = STATIC_ROUTE|Vrf-RED|10.5.6.6/24;
-vrf-name = Vrf-RED
-prefix = 10.5.6.6/24
-nexthop = 10.5.6.1
-distance = 10
-nexthop-vrf = default
-
-````
-
-```
-Note: "show ip route" will show installed static routes along with other routes. "show ip route static" can be used to display only static routes. All show information is fetched from FRR.
-
-Syntax to show static routes
-
-show ip route [vrf ] [static]
-
-sonic# show ip route static
-Codes: K - kernel route, C - connected, S - static, B - BGP, O - OSPF
- > - selected route, * - FIB route, q - queued route, r - rejected route,
- # - not installed in hardware
-
- Destination Gateway Dist/Metric Uptime
-
- S# 3.3.3.0/24 Direct Ethernet4 150/0 00:33:31
- S# 6.6.6.0/24 via 6.6.6.1 Ethernet0 1/0 00:00:03
- S# 7.7.7.0/24 via 7.7.7.1 Ethernet12 36/0 00:01:56
-
-```
-
-
-#### IPv6 examples
-````
-sonic(config)# ipv6 route 2::/64 Ethernet 16
-
-sonic(config)# ipv6 route 2001:FF21:1:1::/64 18:2:1::1 100
-
-sonic(config)# ipv6 route 2111:dddd:0eee::22/128 blackhole 200
-
-Note: "show ipv6 route " will show static routes along with other routes. This information will be fetched from FRR.
- To see only static routes use "show ipv6 route [vrf ] [static]"
-
-sonic(config)# do show ipv6 route vrf
-
-````
-##### 3.6.2.2.2 ipv4 /ipv6 Command to delete a static route.
-
-The vrf is an optional parameter for default instance.
-
-```
-no ip route vrf {[interface ] | [] | [ interface ] | [blackhole]} [nexthop-vrf ]
-
-
-```
-
-```
-no ipv6 route vrf {[interface ] | [] | [ interface ] | [blackhole]} [nexthop-vrf ]
-
-```
-
-##### CLI examples to delete static routes
-````
-sonic(config)# no ip route 10.1.1.1/24 Ethernet 12 nexthop-vrf Vrf-RED
-sonic(config)# no ipv6 route 2::/64 Ethernet 16
-sonic(config)# no ipv6 route 2001:FF21:1:1::/64 18:2:1::1
-````
-
-### 3.6.3 REST API Support
-#### 3.6.3.1
-##### Following REST operations will be supported
-
-1. GET ,POST, PATCH and DELETE supported at /restconf/data/openconfig-network-instance:network-instances/network-instance={name}/protocols/protocol={identifier},{name1}/static-routes
-2. GET , POST, PATCH and DELETE supported at /restconf/data/openconfig-network-instance:network-instances/network-instance={name}/protocols/protocol={identifier},{name1}/static-routes/static={prefix}
-3. GET, POST and DELETE supported at /restconf/data/openconfig-network-instance:network-instances/network-instance={name}/protocols/protocol={identifier},{name1}/static-routes/static={prefix}/next-hops/next-hop={index}
-
-Example of URI:-
-```
-# curl -X PATCH "https://192.168.1.1/restconf/data/openconfig-network-instance:network-instances/network-instance=default/protocols/protocol=STATIC,static/static-routes" -H "accept: application/yang-data+json" -H "Content-Type: application/yang-data+json" -d "{\"openconfig-network-instance:static-routes\": {\"static\": [{\"next-hops\": {\"next-hop\": [{\"index\": \"DROP\", \"config\": {\"index\": \"DROP\", \"blackhole\": true}}]}, \"prefix\": \"21.0.0.0/8\"}]}}" -u admin:xxxxx -k
-
-# curl -kX GET "https://192.168.1.1/restconf/data/openconfig-network-instance:network-instances/network-instance=default/protocols/protocol=STATIC,static/static-routes" -H "accept: application/yang-data+json" -u admin:xxxxx -k | python3 -m json.tool
- % Total % Received % Xferd Average Speed Time Time Time Current
- Dload Upload Total Spent Left Speed
-100 334 100 334 0 0 1397 0 --:--:-- --:--:-- --:--:-- 1409
-{
- "openconfig-network-instance:static-routes": {
- "static": [
- {
- "config": {
- "prefix": "21.0.0.0/8"
- },
- "next-hops": {
- "next-hop": [
- {
- "config": {
- "index": "DROP",
- "openconfig-local-routing-ext:blackhole": true
- },
- "index": "DROP",
- "state": {
- "index": "DROP",
- "openconfig-local-routing-ext:blackhole": true
- }
- }
- ]
- },
- "prefix": "21.0.0.0/8",
- "state": {
- "prefix": "21.0.0.0/8"
- }
- }
- ]
- }
-}
-```
-
-## 3.7 FRR Configuration Support
-### 3.7.1 Configuration Mapping to FRR
-frrcfgd daemon will be used to forward configurations stored in STATIC_ROUTE table to FRR staticd daemon. It will subscribe to listen to STATIC_ROUTE table and if there is data update, it will convert associated data to FRR vtysh command request and send to FRR daemon to configure static route on Linux kernel.
-#### 3.7.1.1 Table entry to command mapping
-FRR vtysh command is composed with VRF/IP_prefix and nexthop data fields in STATIC_ROUTE table entry
-#### FRR command syntax
-```
-configure terminal
-vrf
-[no ]ip route
@@ -268,7 +268,7 @@ Create below config items list for enabling and disabling different table.
### Full Dataset supported
-[OpenBMP dataset](https://github.com/SNAS/openbmp/blob/master/docs/MESSAGE_BUS_API.md#message-api-parsed-data), we can find full dataset info as reference here which is Kafaka based TSV message, however, we will not follow it's format when populats the redis database, the data format we use is decalred [2.4 Database Design](#24-database-design)
+[OpenBMP dataset](https://github.com/SNAS/openbmp/blob/master/docs/MESSAGE_BUS_API.md#message-api-parsed-data), we can find full dataset info as reference here which is Kafaka based TSV message, however, we will not follow it's format when populats the redis database, the data format we use is declared [2.4 Database Design](#24-database-design)
## 2.6 GNMI support
diff --git a/doc/buffer-watermark/align_watermark_flow_with_port_configuration_HLD.md b/doc/buffer-watermark/align_watermark_flow_with_port_configuration_HLD.md
index 930213103b0..3e9860e8e21 100644
--- a/doc/buffer-watermark/align_watermark_flow_with_port_configuration_HLD.md
+++ b/doc/buffer-watermark/align_watermark_flow_with_port_configuration_HLD.md
@@ -1,316 +1,316 @@
-
-# Align watermark flow with port configuration HLD
-
-# High Level Design Document
-## Rev 0.1
-
-# Table of Contents
-- [1. Revision](#1-revision)
-- [2. Scope](#2-scope)
-- [3. Motivation](#3-motivation)
-- [4. Abbreviations](#4-abbreviations)
-- [5. Introduction](#5-introduction)
-- [6. HLD design](#6-hld-design)
- - [6.1 The Requirement](#61-the-requirement)
- - [6.2 Queue and PG maps](#62-queue-and-pg-maps)
- - [6.3 PG and QUEUE map generation correct flows in Flexcounter](#63-pg-and-queue-map-generation-correct-flows-in-flexcounter)
- - [6.4 Change of PG map and QUEUE map generation in flexcounter](#64-change-of-pg-map-and-queue-map-generation-in-flexcounter)
- - [6.5 Effect upon disablement of counterpoll queue/watermark/pg-drop](#65-effect-upon-disablement-of-counterpoll-queue/watermark/pg-drop)
-- [7. Suggested changes](#7-suggested-changes)
- - [7.1 Current flow](#71-current-flow)
- - [7.2 Suggested flow](#72-suggested-flow)
- - [7.3 Addition of port when watermark is enabled](#73-addition-of-port-when-watermark-is-enabled)
-- [8. Testing](#8-testing)
- - [8.1 Manual testing](#81-manual-testing)
- - [8.1.1 Regression testing](#811-test-flex-counter-logic)
- - [8.1.2 Regression testing](#812-test-flex-counter-logic-with-reboot)
- - [8.1.3 Regression testing](#813-adding-a-port-when-watermark-is-enabled)
- - [8.2 VS tests](#82-vs-tests)
-
-# 1. Revision
-| Rev | Date | Author | Change description |
-|:----------:|:----------:|:--------------:|:----------------------:|
-| 0.1 | 17/08/2022 | Doron Barashi | Initial version|
-| | | | |
-
-# 2. Scope
-This document provides high level design for alignment for queue, watermark and pg flows in flexcounter.
-
-# 3. Motivation
-Fix wrong flows existing in flexcounter for queue, watermark and pg counter polling.
-
-# 4. Abbreviations
-
-| Term | Meaning |
-|:--------:|:---------------------------------------------:|
-| PG | Priority Group|
-| PG-DROP | Priority Group drop (packets)|
-
-# 5. Introduction
-
-Currently, the queue map will not be generated if:
-- the watermark counter polling is enabled
-- the queue counter poll is disabled.
-
-This is because there is a missing logic in flexcounter regarding the queue and watermark handling:
-- the queue map is generated only if queue counter polling is enabled
-- the PG map is generated only if PG watermark polling is enabled
-
-This is not complete
-
-Assume the counter polling is disabled for all counters in CONFIG_DB when the system starts,
-- Enable watermark counter polling only
- - PG watermark works correctly
- - *Queue watermark does not work because queue map isn’t generated*
-- Enable pg-drop counter polling only
- - *PG drop counter does not work because PG maps isn’t generated*
- - also pg-watermark stats are not added since PG map generation isn't called
-- Enable queue counter polling only
- - Queue counter works correctly, *but also queue-watermark stats are added*
-
-The branches marked in italic are not expected and caused by the missing logic required in this FR.
-
-# 6. HLD design
-
-## 6.1 The Requirement
-
-- Flexcounter to generate the queue maps when queue or watermark counter is enabled for the 1st time, which means:
- - queue and watermark polling were disabled
- - queue or watermark polling is about to be set to true
-- Flexcounter to generate PG maps when pg-drop or watermark counter is enabled for the 1st time, which means:
- - PG and watermark polling were disabled
- - PG or watermark polling is about to be set to true
-
-## 6.2 Queue and PG maps
-
-These are the Queue and PG maps in COUNTER_DB that should be created upon relevant counterpoll enablement
-
-Queue maps in COUNTERS_DB upon counterpoll queue or watermark enable (currently created only upon queue enable):
-```
-COUNTERS_QUEUE_NAME_MAP
-COUNTERS_QUEUE_INDEX_MAP
-COUNTERS_QUEUE_PORT_MAP
-COUNTERS_QUEUE_TYPE_MAP
-```
-
-PG maps in COUNTERS_DB upon counterpoll pg-drop or watermark enable (currently created only upon pg-watermark enable):
-```
-COUNTERS_PG_NAME_MAP
-COUNTERS_PG_PORT_MAP
-COUNTERS_PG_INDEX_MAP
-```
-
-## 6.3 PG and QUEUE map generation correct flows in Flexcounter
-
-queue enable only:
-
-- QUEUE_STAT_COUNTER should be generated in FLEX_COUNTER_DB
-
-- QUEUE map should be generated in COUNTER_DB
-
-- no WATERMARK stats counters should be generated in flex COUNTER_DB
-
-***Example***
-
-```
-1276) "FLEX_COUNTER_TABLE:QUEUE_STAT_COUNTER:oid:0x15000000000284"
-```
-
-
-pg-drop enable only:
-
-- PG_DROP_STAT_COUNTER should be generated in FLEX_COUNTER_DB
-
-- PG map should be generated in COUNTER_DB
-
-- no *WATERMARK* stats counters should be generated in flex COUNTER_DB
-
-***Example***
-
-```
-642) "FLEX_COUNTER_TABLE:PG_DROP_STAT_COUNTER:oid:0x1a00000000008f"
-```
-
-
-watermark enable only:
-
-- PG_WATERMARK_STAT_COUNTER should be generated in FLEX_COUNTER_DB (db 5)
-- QUEUE_WATERMARK_STAT_COUNTER should be generated in FLEX_COUNTER_DB (db 5)
-- BUFFER_POOL_WATERMARK_STAT_COUNTER should be generated in FLEX_COUNTER_DB (db 5)
-
-- PG_WATERMARK should be generated in COUNTER_DB (db 2)
-- QUEUE_WATERMARK should be generated in COUNTER_DB (db 2)
-- BUFFER_POOL_WATERMARK should be generated in COUNTER_DB (db 2)
-
-***Example***
-
-```
-641) "FLEX_COUNTER_TABLE:PG_WATERMARK_STAT_COUNTER:oid:0x1a0000000000d9"
-642) "FLEX_COUNTER_TABLE:PG_DROP_STAT_COUNTER:oid:0x1a00000000008f"
-```
-
-```
-1276) "FLEX_COUNTER_TABLE:QUEUE_STAT_COUNTER:oid:0x15000000000284"
-1277) "FLEX_COUNTER_TABLE:QUEUE_WATERMARK_STAT_COUNTER:oid:0x150000000002bc"
-```
-
-## 6.4 Change of PG map and QUEUE map generation in flexcounter
-
-QUEUE map generation will be separated into two flows:
-
-- QUEUE map geneartion
-- adding QUEUE or QUEUE_WATERMARK stats to FLEX_COUNTER_DB depending on the counterpoll enabled (queue or watermark)
-
-PG map generation will be separated into two flows:
-
-- PG map geneartion
-- adding PG_DROP or PG_WATERMARK stats to FLEX_COUNTER_DB depending on the counterpoll enabled (pg-drop or watermark)
-
-## 6.5 Effect upon disablement of counterpoll queue/watermark/pg-drop
-
-Current implementation doesn't remove any stats entries from the flexcounter tables in the database upon counterpoll disable.
-No changes will be done for these flows as it's done this way by design.
-
-
-# 7. Suggested changes
-
-## 7.1 Current flow
-
-When queue is enabled in counterpoll, a generateQueueMap function is called in flexcounter.cpp.
-this function calls generateQueueMapPerPort per physical port.
-inside this per port function both the queue map is created and queue-watermark stats are added.
-
-When pg-watermark is enabled in counterpoll, a generatePriorityGroupMap function is called in flexcounter.cpp.
-this function will call generatePriorityGroupMapPerPort per physical port.
-inside this per port function both the pg map is created and pg-watermark stats are added.
-
-***Example***
-
-```
- else if(key == QUEUE_KEY)
- {
- gPortsOrch->generateQueueMap();
- }
- else if(key == PG_WATERMARK_KEY)
- {
- gPortsOrch->generatePriorityGroupMap();
- }
-```
-
-## 7.2 Suggested flow
-
-queue and queue-watermark will be separated:
-
-When queue or watermark is enabled in counterpoll, a generateQueueMap function is called in flexcounter.cpp.
-this function will call generateQueueMapPerPort per physical port.
-inside this per port function only the queue map will be created.
-queue stats creation will be separated into a different inner function that will be called separately if queue counterpoll is enabled.
-
-When only watermark is enabled in counterpoll, this block will call both generateQueueMap and addQueueWatermarkFlexCounters
-which will call addQueueWatermarkFlexCountersPerPort per physical port.
-inside these per port functions both the queue map will be created and queue-watermark stats will be added respectively.
-
-pg and pg-watermark will be separated:
-
-When pg-drop or watermark is enabled in counterpoll, a generatePriorityGroupMap function is called in flexcounter.cpp.
-this function will call generatePriorityGroupMapPerPort per physical port.
-inside this per port function only PG map will be created.
-pg-drop stats creation will be separated into a different inner function that will be called separately if pg-drop counterpoll is enabled.
-
-When only watermark is enabled in counterpoll, this block will call both generatePriorityGroupMap abd addPriorityGroupWatermarkFlexCounters function
-which will call addPriorityGroupWatermarkFlexCountersPerPort per physical port.
-inside this per port functions both the PG map will be created and pg-watermark stats will be added respectively.
-
-
-***Example***
-
-```
- else if(key == QUEUE_KEY)
- {
- gPortsOrch->generateQueueMap();
- gPortsOrch->addQueueFlexCounters();
- }
- else if(key == QUEUE_WATERMARK)
- {
- gPortsOrch->generateQueueMap();
- gPortsOrch->addQueueWatermarkFlexCounters();
- }
- else if(key == PG_DROP_KEY)
- {
- gPortsOrch->generatePriorityGroupMap();
- gPortsOrch->addPriorityGroupDropFlexCounters();
- }
- else if(key == PG_WATERMARK_KEY)
- {
- gPortsOrch->generatePriorityGroupMap();
- gPortsOrch->addPriorityGroupWatermarkFlexCounters();
- }
-```
-
-if queue or PG maps already created upon queue or pg-drop enablement and then watermark is enabled,
-the queue or PG maps won't be created again.
-this is done using the private boolean storing the created status. if it's already true, function returns.
-the same mechanism will be done in the new watermark functions.
-
-***PG map Example***
-
-```
- if (m_isPriorityGroupMapGenerated)
- {
- return;
- }
-```
-
-## 7.3 Addition of port when watermark is enabled
-
-when watermark counterpoll is enabled and a certaion port will be added, the watermark stats for this port will be added.
-
-# 8. Testing
-
-## 8.1 Manual testing
-
-### 8.1.1 test flex counter logic
-Test_flex_counter_logic(type=[watermark,queue,pg-drop]:
-1. Disable the counter polling for all counters and save, reload configuration
-2. Switch (type)
- - watermark: enable the watermark counter polling, check whether PG and queue map are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
- - queue: enable the queue counter polling, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
- - pg-drop: enable the pg-drop counter polling, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
-
-repeat this test 3 times, each time with different type [watermark,queue,pg-drop]
-
-### 8.1.2 test flex counter logic with reboot
-Test_flex_counter_logic(type=[watermark,queue,pg-drop] reboot after counterpoll enable:
-1. Disable the counter polling for all counters and save, reload configuration
-2. Switch (type)
- - watermark: enable the watermark counter polling, check whether PG and queue map are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
- - queue: enable the queue counter polling, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
- - pg-drop: enable the pg-drop counter polling, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
-3. reboot switch
- Switch (type)
- - watermark: watermark counter polling is enabled, check that PG and queue maps are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
- - queue: queue counter polling is enabled, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
- - pg-drop: pg-drop counter polling is enabled, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
-
-### 8.1.3 Adding a port when watermark is enabled
-
-1. disable a port
-2. enable watermark counterpoll
-3. verify this port stats does not exist in FLEX_COUNTERs_DB and COUNTERS_DB
-4. enable the port previously disabled
-5. verify this port stats is added to FLEX_COUNTERs_DB and COUNTERS_DB
-
-## 8.2 VS tests
-
-- Add queue-watermark and pg-drop to swss/test_flex_counters.py test
- before this change only queue and pg-watermark are tested according to the old code implementation
-
-- Test_flex_counter_logic(type=[watermark,queue,pg-drop]:
-
-repeat this test 3 times, each time with different type [watermark,queue,pg-drop]
-Test_flex_counter_logic(type=[watermark,queue,pg-drop] reboot after counterpoll enable:
-1. Disable the counter polling for all counters and save, reload configuration
-2. Switch (type)
- - watermark: enable the watermark counter polling, check whether PG and queue map are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
- - queue: enable the queue counter polling, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
- - pg-drop: enable the pg-drop counter polling, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+
+# Align watermark flow with port configuration HLD
+
+# High Level Design Document
+## Rev 0.1
+
+# Table of Contents
+- [1. Revision](#1-revision)
+- [2. Scope](#2-scope)
+- [3. Motivation](#3-motivation)
+- [4. Abbreviations](#4-abbreviations)
+- [5. Introduction](#5-introduction)
+- [6. HLD design](#6-hld-design)
+ - [6.1 The Requirement](#61-the-requirement)
+ - [6.2 Queue and PG maps](#62-queue-and-pg-maps)
+ - [6.3 PG and QUEUE map generation correct flows in Flexcounter](#63-pg-and-queue-map-generation-correct-flows-in-flexcounter)
+ - [6.4 Change of PG map and QUEUE map generation in flexcounter](#64-change-of-pg-map-and-queue-map-generation-in-flexcounter)
+ - [6.5 Effect upon disablement of counterpoll queue/watermark/pg-drop](#65-effect-upon-disablement-of-counterpoll-queue/watermark/pg-drop)
+- [7. Suggested changes](#7-suggested-changes)
+ - [7.1 Current flow](#71-current-flow)
+ - [7.2 Suggested flow](#72-suggested-flow)
+ - [7.3 Addition of port when watermark is enabled](#73-addition-of-port-when-watermark-is-enabled)
+- [8. Testing](#8-testing)
+ - [8.1 Manual testing](#81-manual-testing)
+ - [8.1.1 Regression testing](#811-test-flex-counter-logic)
+ - [8.1.2 Regression testing](#812-test-flex-counter-logic-with-reboot)
+ - [8.1.3 Regression testing](#813-adding-a-port-when-watermark-is-enabled)
+ - [8.2 VS tests](#82-vs-tests)
+
+# 1. Revision
+| Rev | Date | Author | Change description |
+|:----------:|:----------:|:--------------:|:----------------------:|
+| 0.1 | 17/08/2022 | Doron Barashi | Initial version|
+| | | | |
+
+# 2. Scope
+This document provides high level design for alignment for queue, watermark and pg flows in flexcounter.
+
+# 3. Motivation
+Fix wrong flows existing in flexcounter for queue, watermark and pg counter polling.
+
+# 4. Abbreviations
+
+| Term | Meaning |
+|:--------:|:---------------------------------------------:|
+| PG | Priority Group|
+| PG-DROP | Priority Group drop (packets)|
+
+# 5. Introduction
+
+Currently, the queue map will not be generated if:
+- the watermark counter polling is enabled
+- the queue counter poll is disabled.
+
+This is because there is a missing logic in flexcounter regarding the queue and watermark handling:
+- the queue map is generated only if queue counter polling is enabled
+- the PG map is generated only if PG watermark polling is enabled
+
+This is not complete
+
+Assume the counter polling is disabled for all counters in CONFIG_DB when the system starts,
+- Enable watermark counter polling only
+ - PG watermark works correctly
+ - *Queue watermark does not work because queue map isn’t generated*
+- Enable pg-drop counter polling only
+ - *PG drop counter does not work because PG maps isn’t generated*
+ - also pg-watermark stats are not added since PG map generation isn't called
+- Enable queue counter polling only
+ - Queue counter works correctly, *but also queue-watermark stats are added*
+
+The branches marked in italic are not expected and caused by the missing logic required in this FR.
+
+# 6. HLD design
+
+## 6.1 The Requirement
+
+- Flexcounter to generate the queue maps when queue or watermark counter is enabled for the 1st time, which means:
+ - queue and watermark polling were disabled
+ - queue or watermark polling is about to be set to true
+- Flexcounter to generate PG maps when pg-drop or watermark counter is enabled for the 1st time, which means:
+ - PG and watermark polling were disabled
+ - PG or watermark polling is about to be set to true
+
+## 6.2 Queue and PG maps
+
+These are the Queue and PG maps in COUNTER_DB that should be created upon relevant counterpoll enablement
+
+Queue maps in COUNTERS_DB upon counterpoll queue or watermark enable (currently created only upon queue enable):
+```
+COUNTERS_QUEUE_NAME_MAP
+COUNTERS_QUEUE_INDEX_MAP
+COUNTERS_QUEUE_PORT_MAP
+COUNTERS_QUEUE_TYPE_MAP
+```
+
+PG maps in COUNTERS_DB upon counterpoll pg-drop or watermark enable (currently created only upon pg-watermark enable):
+```
+COUNTERS_PG_NAME_MAP
+COUNTERS_PG_PORT_MAP
+COUNTERS_PG_INDEX_MAP
+```
+
+## 6.3 PG and QUEUE map generation correct flows in Flexcounter
+
+queue enable only:
+
+- QUEUE_STAT_COUNTER should be generated in FLEX_COUNTER_DB
+
+- QUEUE map should be generated in COUNTER_DB
+
+- no WATERMARK stats counters should be generated in flex COUNTER_DB
+
+***Example***
+
+```
+1276) "FLEX_COUNTER_TABLE:QUEUE_STAT_COUNTER:oid:0x15000000000284"
+```
+
+
+pg-drop enable only:
+
+- PG_DROP_STAT_COUNTER should be generated in FLEX_COUNTER_DB
+
+- PG map should be generated in COUNTER_DB
+
+- no *WATERMARK* stats counters should be generated in flex COUNTER_DB
+
+***Example***
+
+```
+642) "FLEX_COUNTER_TABLE:PG_DROP_STAT_COUNTER:oid:0x1a00000000008f"
+```
+
+
+watermark enable only:
+
+- PG_WATERMARK_STAT_COUNTER should be generated in FLEX_COUNTER_DB (db 5)
+- QUEUE_WATERMARK_STAT_COUNTER should be generated in FLEX_COUNTER_DB (db 5)
+- BUFFER_POOL_WATERMARK_STAT_COUNTER should be generated in FLEX_COUNTER_DB (db 5)
+
+- PG_WATERMARK should be generated in COUNTER_DB (db 2)
+- QUEUE_WATERMARK should be generated in COUNTER_DB (db 2)
+- BUFFER_POOL_WATERMARK should be generated in COUNTER_DB (db 2)
+
+***Example***
+
+```
+641) "FLEX_COUNTER_TABLE:PG_WATERMARK_STAT_COUNTER:oid:0x1a0000000000d9"
+642) "FLEX_COUNTER_TABLE:PG_DROP_STAT_COUNTER:oid:0x1a00000000008f"
+```
+
+```
+1276) "FLEX_COUNTER_TABLE:QUEUE_STAT_COUNTER:oid:0x15000000000284"
+1277) "FLEX_COUNTER_TABLE:QUEUE_WATERMARK_STAT_COUNTER:oid:0x150000000002bc"
+```
+
+## 6.4 Change of PG map and QUEUE map generation in flexcounter
+
+QUEUE map generation will be separated into two flows:
+
+- QUEUE map generation
+- adding QUEUE or QUEUE_WATERMARK stats to FLEX_COUNTER_DB depending on the counterpoll enabled (queue or watermark)
+
+PG map generation will be separated into two flows:
+
+- PG map generation
+- adding PG_DROP or PG_WATERMARK stats to FLEX_COUNTER_DB depending on the counterpoll enabled (pg-drop or watermark)
+
+## 6.5 Effect upon disablement of counterpoll queue/watermark/pg-drop
+
+Current implementation doesn't remove any stats entries from the flexcounter tables in the database upon counterpoll disable.
+No changes will be done for these flows as it's done this way by design.
+
+
+# 7. Suggested changes
+
+## 7.1 Current flow
+
+When queue is enabled in counterpoll, a generateQueueMap function is called in flexcounter.cpp.
+this function calls generateQueueMapPerPort per physical port.
+inside this per port function both the queue map is created and queue-watermark stats are added.
+
+When pg-watermark is enabled in counterpoll, a generatePriorityGroupMap function is called in flexcounter.cpp.
+this function will call generatePriorityGroupMapPerPort per physical port.
+inside this per port function both the pg map is created and pg-watermark stats are added.
+
+***Example***
+
+```
+ else if(key == QUEUE_KEY)
+ {
+ gPortsOrch->generateQueueMap();
+ }
+ else if(key == PG_WATERMARK_KEY)
+ {
+ gPortsOrch->generatePriorityGroupMap();
+ }
+```
+
+## 7.2 Suggested flow
+
+queue and queue-watermark will be separated:
+
+When queue or watermark is enabled in counterpoll, a generateQueueMap function is called in flexcounter.cpp.
+this function will call generateQueueMapPerPort per physical port.
+inside this per port function only the queue map will be created.
+queue stats creation will be separated into a different inner function that will be called separately if queue counterpoll is enabled.
+
+When only watermark is enabled in counterpoll, this block will call both generateQueueMap and addQueueWatermarkFlexCounters
+which will call addQueueWatermarkFlexCountersPerPort per physical port.
+inside these per port functions both the queue map will be created and queue-watermark stats will be added respectively.
+
+pg and pg-watermark will be separated:
+
+When pg-drop or watermark is enabled in counterpoll, a generatePriorityGroupMap function is called in flexcounter.cpp.
+this function will call generatePriorityGroupMapPerPort per physical port.
+inside this per port function only PG map will be created.
+pg-drop stats creation will be separated into a different inner function that will be called separately if pg-drop counterpoll is enabled.
+
+When only watermark is enabled in counterpoll, this block will call both generatePriorityGroupMap and addPriorityGroupWatermarkFlexCounters function
+which will call addPriorityGroupWatermarkFlexCountersPerPort per physical port.
+inside this per port functions both the PG map will be created and pg-watermark stats will be added respectively.
+
+
+***Example***
+
+```
+ else if(key == QUEUE_KEY)
+ {
+ gPortsOrch->generateQueueMap();
+ gPortsOrch->addQueueFlexCounters();
+ }
+ else if(key == QUEUE_WATERMARK)
+ {
+ gPortsOrch->generateQueueMap();
+ gPortsOrch->addQueueWatermarkFlexCounters();
+ }
+ else if(key == PG_DROP_KEY)
+ {
+ gPortsOrch->generatePriorityGroupMap();
+ gPortsOrch->addPriorityGroupDropFlexCounters();
+ }
+ else if(key == PG_WATERMARK_KEY)
+ {
+ gPortsOrch->generatePriorityGroupMap();
+ gPortsOrch->addPriorityGroupWatermarkFlexCounters();
+ }
+```
+
+if queue or PG maps already created upon queue or pg-drop enablement and then watermark is enabled,
+the queue or PG maps won't be created again.
+this is done using the private boolean storing the created status. if it's already true, function returns.
+the same mechanism will be done in the new watermark functions.
+
+***PG map Example***
+
+```
+ if (m_isPriorityGroupMapGenerated)
+ {
+ return;
+ }
+```
+
+## 7.3 Addition of port when watermark is enabled
+
+when watermark counterpoll is enabled and a certain port will be added, the watermark stats for this port will be added.
+
+# 8. Testing
+
+## 8.1 Manual testing
+
+### 8.1.1 test flex counter logic
+Test_flex_counter_logic(type=[watermark,queue,pg-drop]:
+1. Disable the counter polling for all counters and save, reload configuration
+2. Switch (type)
+ - watermark: enable the watermark counter polling, check whether PG and queue map are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
+ - queue: enable the queue counter polling, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+ - pg-drop: enable the pg-drop counter polling, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+
+repeat this test 3 times, each time with different type [watermark,queue,pg-drop]
+
+### 8.1.2 test flex counter logic with reboot
+Test_flex_counter_logic(type=[watermark,queue,pg-drop] reboot after counterpoll enable:
+1. Disable the counter polling for all counters and save, reload configuration
+2. Switch (type)
+ - watermark: enable the watermark counter polling, check whether PG and queue map are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
+ - queue: enable the queue counter polling, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+ - pg-drop: enable the pg-drop counter polling, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+3. reboot switch
+ Switch (type)
+ - watermark: watermark counter polling is enabled, check that PG and queue maps are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
+ - queue: queue counter polling is enabled, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+ - pg-drop: pg-drop counter polling is enabled, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+
+### 8.1.3 Adding a port when watermark is enabled
+
+1. disable a port
+2. enable watermark counterpoll
+3. verify this port stats does not exist in FLEX_COUNTERs_DB and COUNTERS_DB
+4. enable the port previously disabled
+5. verify this port stats is added to FLEX_COUNTERs_DB and COUNTERS_DB
+
+## 8.2 VS tests
+
+- Add queue-watermark and pg-drop to swss/test_flex_counters.py test
+ before this change only queue and pg-watermark are tested according to the old code implementation
+
+- Test_flex_counter_logic(type=[watermark,queue,pg-drop]:
+
+repeat this test 3 times, each time with different type [watermark,queue,pg-drop]
+Test_flex_counter_logic(type=[watermark,queue,pg-drop] reboot after counterpoll enable:
+1. Disable the counter polling for all counters and save, reload configuration
+2. Switch (type)
+ - watermark: enable the watermark counter polling, check whether PG and queue map are generated in COUNTER_DB and both PG and QUEUE WATERMARK stats exists in FLEX_COUNTER_DB
+ - queue: enable the queue counter polling, check whether queue map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
+ - pg-drop: enable the pg-drop counter polling, check whether PG map is generated in COUNTER_DB, no *WATERMARK* stats in FLEX_COUNTER_DB
diff --git a/doc/buffer-watermark/align_watermark_flow_with_port_configuration_test_plan.md b/doc/buffer-watermark/align_watermark_flow_with_port_configuration_test_plan.md
index f7969c7719e..a61fcf90641 100644
--- a/doc/buffer-watermark/align_watermark_flow_with_port_configuration_test_plan.md
+++ b/doc/buffer-watermark/align_watermark_flow_with_port_configuration_test_plan.md
@@ -49,7 +49,7 @@ The purpose of this test plan is to describe tests for Align watermark flow with
## Test information
### Supported topology
-The test will be supported on any toplogy, since it doesn't require any traffic,
+The test will be supported on any topology, since it doesn't require any traffic,
except configuring port buffers since a performance improvement in queue and pg-drop maps creation was merged few days ago.
### Test configuration
diff --git a/doc/buffer-watermark/watermarks_HLD.md b/doc/buffer-watermark/watermarks_HLD.md
index c7600e27e85..02f606a1562 100644
--- a/doc/buffer-watermark/watermarks_HLD.md
+++ b/doc/buffer-watermark/watermarks_HLD.md
@@ -232,7 +232,7 @@ In addition clear functionality will be added:
# clear queue [watermark|persistent-watermark] unicast
-# clear queue [watermark|persistent-watermark] mutlicast
+# clear queue [watermark|persistent-watermark] multicast
```
The user can clear the persistent watermark, and the "user" watermark. The user can not clear the periodic(telemetry) watermark. The clear command requires sudo, as the watermark is shared for
@@ -240,7 +240,7 @@ all users, and clear will affect every user(if a number of people are connected
#### 3.1.2.3 Show/configure telemetry interval
-The telemetry interval will be available for viewing and configuring with the folowing CLI:
+The telemetry interval will be available for viewing and configuring with the following CLI:
```
$ show watermark telemetry interval
@@ -317,7 +317,7 @@ The sai APIs anf calls are:
### 3.1.9 gRPC
-Sonic-telemetry will have acess to data in WATERMARK an HIGHEST_WATERMARK tables. For this the virtual db should be extended to access the said tables, virual path should should support mapping
+Sonic-telemetry will have access to data in WATERMARK an HIGHEST_WATERMARK tables. For this the virtual db should be extended to access the said tables, virtual path should should support mapping
ports to queues and priority groups. The exact syntax of the virtual paths is TBD.
Examples of virtual paths:
@@ -341,11 +341,11 @@ Examples of virtual paths:
The core components are the flex counter, watermark orch, DB, CLI.
-The flex counter reads and clears the watermarks on a peroid of 1s by default. The values are put directly to COUNTERS table. The flex counter also has plugins configured for queue and pg, which will be triggered on every flex counter group interval. The lua plugin will update PERIODIC_WATERMARKS, PERSISTENT_WATERMARKS and USER_WATERMARKS with if the new value exceeds the vlaue that was read from the table.
+The flex counter reads and clears the watermarks on a period of 1s by default. The values are put directly to COUNTERS table. The flex counter also has plugins configured for queue and pg, which will be triggered on every flex counter group interval. The lua plugin will update PERIODIC_WATERMARKS, PERSISTENT_WATERMARKS and USER_WATERMARKS with if the new value exceeds the value that was read from the table.
The watermark orch has 2 main functions:
- Handle the Timer that clears the PERIODIC_WATERMARKS table. Handle the configuring of the interval for the timer.
- - Handle Clear notificatons. On clear event the orch should just zero-out the corresponding watermarks from the table. It will be soon repopulated by lua plugin.
+ - Handle Clear notifications. On clear event the orch should just zero-out the corresponding watermarks from the table. It will be soon repopulated by lua plugin.
The DB contains all the tables with watemarks, and the configuration table.
diff --git a/doc/bulk_counter/bulk_counter.md b/doc/bulk_counter/bulk_counter.md
index 4bae67fa0b9..eff41b5223c 100644
--- a/doc/bulk_counter/bulk_counter.md
+++ b/doc/bulk_counter/bulk_counter.md
@@ -121,7 +121,7 @@ Furthermore, the bulk chunk size can be configured on a per counter IDs set basi
Each `COUNTER_NAME_PREFIX` defines a set of counter IDs by matching the counter IDs with the prefix. All the counter IDs in each set share a unified bulk chunk size and will be polled in a series of bulk counter polling API calls with the same counter IDs set but different port set.
All such sets of counter IDs form a partition of counter IDs of the flex counter group. The partition of a flex counter group is represented by the keys of map `m_portBulkContexts`.
-To simplify the logic, it is not supported to change the partition, which means it does not allow to split counter IDs into a differet sub sets once they have been split.
+To simplify the logic, it is not supported to change the partition, which means it does not allow to split counter IDs into a different sub sets once they have been split.
Eg. `SAI_PORT_STAT_IF_IN_FEC:32,SAI_PORT_STAT_IF_OUT_QLEN:0` represents
@@ -189,7 +189,7 @@ The following new types will be introduced in `container FLEX_COUNTER_TABLE` of
/}
```
-In the yang model, each flex counter group is an independent countainer. We will define leaf in the countainer `PG_DROP`, `PG_WATERMARK`, `PORT`, `QUEUE`, `QUEUE_WATERMARK`.
+In the yang model, each flex counter group is an independent container. We will define leaf in the container `PG_DROP`, `PG_WATERMARK`, `PORT`, `QUEUE`, `QUEUE_WATERMARK`.
The update of `PG_DROP` is shown as below
```
@@ -248,6 +248,6 @@ As this feature does not introduce any new function, unit test shall be good eno
An example shows how smaller bulk chunk size helps PFC watchdog counter polling thread to be scheduled in time.
-In the upper chart, the port counters are polled in a single bulk call which takes longer time. The PFC watchdog counter polling thread can not procceed until the long bulk call exits the critical section.
+In the upper chart, the port counters are polled in a single bulk call which takes longer time. The PFC watchdog counter polling thread can not proceed until the long bulk call exits the critical section.
In the lower chart, the port counters are polled in a series of bulk call with smaller bulk chunk sizes. The PFC watchdog counter polling thread has more chance to be scheduled in time.
diff --git a/doc/bum_storm_control/bum_storm_control_hld.md b/doc/bum_storm_control/bum_storm_control_hld.md
index 3eff1943131..6239977b511 100644
--- a/doc/bum_storm_control/bum_storm_control_hld.md
+++ b/doc/bum_storm_control/bum_storm_control_hld.md
@@ -87,7 +87,7 @@ This document describes the functionality and high level design of Broadcast, Un
# 1 Feature Overview
A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. The type of traffic can be Broadcast, Unknown-unicast or unknown-Multicast (BUM).
The storm-control feature allows the user to limit the amount of BUM traffic admitted to the system. This can be achieved by configuring the type of storm (Broadcast or Unknown-unicast or unknown-Multicast) and the corresponding kilo bits per second (kbps) parameter on a given physical interface. Traffic that exceeds the configured rate will be dropped.
-Unknown-multicast traffic consists of all multicast traffic which donot match any of the statically configured or dynamically learned multicast groups.
+Unknown-multicast traffic consists of all multicast traffic which do not match any of the statically configured or dynamically learned multicast groups.
diff --git a/doc/cbf/cbf_hld.md b/doc/cbf/cbf_hld.md
index 17e6c730eae..4714dd27377 100644
--- a/doc/cbf/cbf_hld.md
+++ b/doc/cbf/cbf_hld.md
@@ -53,7 +53,7 @@ DSCP/EXP value of W for --> in the DSCP/EXP to FC --> assigned to the --> lookup
destination D map table for W packet for destination D is a CBF group of Y based on the FC destination D
value X
```
-This feature enables opeartors, among other things, to send the important (foreground) traffic through the shortest path, while sending the background traffic through longer paths to still give it some bandwidth instead of using QoS queues which may block background traffic from getting bandwitdh.
+This feature enables operators, among other things, to send the important (foreground) traffic through the shortest path, while sending the background traffic through longer paths to still give it some bandwidth instead of using QoS queues which may block background traffic from getting bandwidth.
These new class based next hop groups are allowed thanks to the changes in https://github.com/opencomputeproject/SAI/pull/1193, which allow a next hop group object to also have other next hop group objects as members of the group along with the next hop objects. The way such a next hop group works is that a packet which has a Forwarding Class value of X will be matched against an appropriate member of this group, selected based on the Forwarding Class value thanks to the "selection_map" property of the group. As an example, given the CBF group with members Nhg1, Nhg2 and Nhg3 and a selection map of FC 0 -> Nhg1, FC 1 -> Nhg2 and FC 3 -> Nhg3, a packet which has an FC value of 0 will be forwarded using Nhg1. Note that multiple FC values can point to the same member, but a single FC value can't be mapped to more than one member.
diff --git a/doc/cli_auto_generation/cli_auto_generation.md b/doc/cli_auto_generation/cli_auto_generation.md
index fc88a8a3826..bedac326159 100644
--- a/doc/cli_auto_generation/cli_auto_generation.md
+++ b/doc/cli_auto_generation/cli_auto_generation.md
@@ -136,10 +136,10 @@ The [manifest.json](https://github.com/stepanblyschak/SONiC/blob/sonic-app-ext-3
| Path | Type | Mandatory | Description |
| --------------------------------- | ------ | --------- | ------------------------------------------------------------------------- |
-| /cli/auto-generate-config | boolean| yes | ON/OFF triger for auto-generation of CLI command *config*. Default: false |
-| /cli/auto-generate-show | boolean| yes | ON/OFF triger for auto-generation of CLI command *show*. Default: false |
+| /cli/auto-generate-config | boolean| yes | ON/OFF trigger for auto-generation of CLI command *config*. Default: false |
+| /cli/auto-generate-show | boolean| yes | ON/OFF trigger for auto-generation of CLI command *show*. Default: false |
-By default, CLI is autogenerated for all YANG modules provided by the extension. Developer can optionally specify explicitelly which YANG modules to use for auto-generated CLI:
+By default, CLI is autogenerated for all YANG modules provided by the extension. Developer can optionally specify explicitly which YANG modules to use for auto-generated CLI:
| Path | Type | Mandatory | Description |
| --------------------------------- | ------ | --------- | ------------------------------------------------------------------------- |
@@ -296,7 +296,7 @@ ACS-MSN2100 UP r-sonic-switch x86_64-mlnx_msn2100-r0
```
{
"DEVICE_METADATA": {
- "locahost": {
+ "localhost": {
"hwsku": "ACS-MSN2100",
"default_bgp_status": "up",
"hostname": "r-sonic-switch",
diff --git a/doc/cmis-module-enhancement/cmis-module-enhancement.md b/doc/cmis-module-enhancement/cmis-module-enhancement.md
index f7005513b09..9cb75a75a25 100644
--- a/doc/cmis-module-enhancement/cmis-module-enhancement.md
+++ b/doc/cmis-module-enhancement/cmis-module-enhancement.md
@@ -11,7 +11,7 @@
## 2. Scope
-This section describes an enhancment of the synchronization between ASIC port and module configuration.
+This section describes an enhancement of the synchronization between ASIC port and module configuration.
## 3. Definitions/Abbreviations
@@ -26,7 +26,7 @@ These initialization processes should be synchronized and the configuration of C
Currently, SONIC uses the "host_tx_ready" flag in the PORT table in STATE DB for synchronization. This flag is set by Ports OA right after the SAI API for setting the Admin status to UP returns with OK/Success status. PMON registers for changes of this flag in Redis DB and starts the CMIS initialization for a particular module when this flag is set.
Current design has some gaps with synchronization between ASIC and module configuration.
-This document purpose is to introduce an enhacement that will address the gaps and find a backward compatible solution.
+This document purpose is to introduce an enhancement that will address the gaps and find a backward compatible solution.
## 5. Requirements
@@ -37,7 +37,7 @@ This document purpose is to introduce an enhacement that will address the gaps a
* Vendor SDK/FW shall support asynchronous notification of start/stop of sending high-speed signal from ASIC to module.
-* PortsOrch shall set host_tx_ready in state DB, only when it recieved notification that the high-speed signal is sent.
+* PortsOrch shall set host_tx_ready in state DB, only when it received notification that the high-speed signal is sent.
## 6. High-Level Design
@@ -81,7 +81,7 @@ High Level Flow:
#### 6.2.1. host_tx_signal
This flow shall be used only on supporting platforms.
-Hence, as part of PortsOrch initialization, SONiC will query SAI capabilities regarding the support of allowence flag for sending high-speed signal to module - It will be done by checking if SAI_PORT_ATTR_HOST_TX_SIGNAL_ENABLE is supported.
+Hence, as part of PortsOrch initialization, SONiC will query SAI capabilities regarding the support of allowance flag for sending high-speed signal to module - It will be done by checking if SAI_PORT_ATTR_HOST_TX_SIGNAL_ENABLE is supported.
In case SAI supports it, PortsOrch will start listening to TRANSCEIVER_INFO in State DB to know on any module plug event.
Module's INSERTION/REMOVAL events shall trigger the calling of SAI API on a Port object with SAI_PORT_ATTR_HOST_TX_SIGNAL_ENABLE to enable or disable data signal from ASIC to module.
diff --git a/doc/config-generic-update-rollback/Json_Change_Application_Design.md b/doc/config-generic-update-rollback/Json_Change_Application_Design.md
index f5a914a2ff5..fb076d33ece 100644
--- a/doc/config-generic-update-rollback/Json_Change_Application_Design.md
+++ b/doc/config-generic-update-rollback/Json_Change_Application_Design.md
@@ -127,7 +127,7 @@ void apply-change(JsonChange jsonChange)
|errors |malformedChangeError | Will be raised if the input JsonChange is not valid according to [SONiC_Generic_Config_Update_and_Rollback_Design](SONiC_Generic_Config_Update_and_Rollback_Design.md#31141-jsonchange).
| |other errors | Check [SONiC_Generic_Config_Update_and_Rollback_Design](SONiC_Generic_Config_Update_and_Rollback_Design.md#31141-apply-change) for exact list of errors to expect.
|side-effects|updating running-config| This operation will cause changes to the running-config according to the input JsonChange.
-|assumptions |running-config locked| The implementor of this contract will interact with ConfigDB to updating the running-config, it is assumed the running-config is locked for changes for the lifespan of the operation.
+|assumptions |running-config locked| The implementer of this contract will interact with ConfigDB to updating the running-config, it is assumed the running-config is locked for changes for the lifespan of the operation.
The important constraint in the above interface is the JsonChange, where ordering of applying the modifications is arbitrary.
@@ -224,7 +224,7 @@ Or it can be updated using the following steps:
{ "op": "add", "path": "/DHCP_SERVER/192.0.0.3", "value": {} },
```
-Applying JsonChange is all about the running config being converted to the target config, the steps to update can be arbitrary and are decided by the implementor of the `apply-change` interface.
+Applying JsonChange is all about the running config being converted to the target config, the steps to update can be arbitrary and are decided by the implementer of the `apply-change` interface.
Our current design documents will use the "Table" as the main granular element of update. We will update "Table" by "Table" in alphabetical order. Each table update will take care of updating table entries in ConfigDB, restarting services if needed and verifying services have absorbed
diff --git a/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md b/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md
index 926d06725d6..964eacb7b20 100644
--- a/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md
+++ b/doc/config-generic-update-rollback/Json_Patch_Ordering_using_YANG_Models_Design.md
@@ -119,7 +119,7 @@ list
-This will allow the the implementor of `apply-change` to have the freedom to optimize the operations in any order they see fit.
+This will allow the the implementer of `apply-change` to have the freedom to optimize the operations in any order they see fit.
**NOTE:** Check Patch Orderer implementation design design details in [Json_Patch_Ordering_using_YANG_Models_Design](Json_Patch_Ordering_using_YANG_Models_Design.md) document.
@@ -668,9 +668,9 @@ void apply-change(JsonChange jsonChange)
| |unprocessableRequestError| Will be raised if the change is valid, all the resources are found but when applying the change it causes an error in the system.
| |internalError | Will be raised if any other error is encountered that's different than the ones listed above.
|side-effects|updating running-config | This operation will cause changes to the running-config according to the input JsonChange.
-|assumptions |running-config locked | The implementor of this contract will interact with ConfigDB to updating the running-config, it is assumed the ConfigDB is locked for changes for the lifespan of the operation.
+|assumptions |running-config locked | The implementer of this contract will interact with ConfigDB to updating the running-config, it is assumed the ConfigDB is locked for changes for the lifespan of the operation.
-Since the order of executing the operation does not matter, the implementor of this component can work on optimizing the time to run the operation. For details check [3.1.1.4 Change Applier](#3115-change-applier).
+Since the order of executing the operation does not matter, the implementer of this component can work on optimizing the time to run the operation. For details check [3.1.1.4 Change Applier](#3115-change-applier).
**NOTE:** Check Change Applier implementation design design details in [Json_Change_Application_Design](Json_Change_Application_Design.md) document.
@@ -695,7 +695,7 @@ Same as [3.1.1.3 YANG models](#3113-yang-models)
same as [3.1.1.5 ConfigDB](#3115-configdb)
#### 3.1.2.5 File system
-This will the file system where SONiC os is setup. Some suggestions prefer the path `/var/sonic/checkpoints`, but that is not decided yet. Will leave it to the implementor of this design document to decide.
+This will the file system where SONiC os is setup. Some suggestions prefer the path `/var/sonic/checkpoints`, but that is not decided yet. Will leave it to the implementer of this design document to decide.
### 3.1.3 Rollback
@@ -736,7 +736,7 @@ same as [3.1.1.5 ConfigDB](#3115-configdb)
#### 3.2.1.1 JsonPatch
-The JsonPatch consistes of a list operation, and each operation follows this format:
+The JsonPatch consists of a list operation, and each operation follows this format:
```
{ "op": "
-It can be seen from Figure 1, it is possible that punt-header-v1 reachs SONIC-v2 or inject-header-v2 reachs NPU-v1 during t1 to t2 window. The punt and inject header changes are rare and not commom. Currently punt and inject header data structure differences between V1 and V2 are handled case by case basis in S1 SDK internally. A more generic and scalable approach for it is being planned and will be shared with the community as an express boot phase-2 once it is finalized. But in principle, maintaining backward compatibility in punt-inject-header if there are any changes is essential for successful express boot upgrades.
+It can be seen from Figure 1, it is possible that punt-header-v1 reaches SONIC-v2 or inject-header-v2 reaches NPU-v1 during t1 to t2 window. The punt and inject header changes are rare and not common. Currently punt and inject header data structure differences between V1 and V2 are handled case by case basis in S1 SDK internally. A more generic and scalable approach for it is being planned and will be shared with the community as an express boot phase-2 once it is finalized. But in principle, maintaining backward compatibility in punt-inject-header if there are any changes is essential for successful express boot upgrades.
Figure 2 below compares major steps taken in warm boot and express boot from both SONiC and SDK point of view.
diff --git a/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md b/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md
index 280a9b6336e..899ce2c5fd6 100644
--- a/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md
+++ b/doc/fast-reboot/Fast-reboot_Flow_Improvements_HLD.md
@@ -27,7 +27,7 @@
The goal of SONiC fast-reboot is to be able to restart and upgrade SONiC software with a data plane disruption less than 30 seconds and control plane less than 90 seconds.
With current implementation there is no indication of the fast-reboot status, meaning we don't have a way to determine if the flow has finished or not.
-Some feature flows in SONiC are delayed with a timer to keep the CPU dedicated to the fast-reboot init flow for best perforamnce, like enablement of flex counters.
+Some feature flows in SONiC are delayed with a timer to keep the CPU dedicated to the fast-reboot init flow for best performance, like enablement of flex counters.
In order to have such indicator, re-use of the fastfast-reboot infrastructure can be used.
Each network application will experience similar processing flow.
@@ -48,7 +48,7 @@ https://github.com/sonic-net/sonic-buildimage/blob/master/dockers/docker-orchage
# 2 Functional Requirements
-The new Fast-reboot design should meet the following requirments:
+The new Fast-reboot design should meet the following requirements:
- Reboot the switch into a new SONiC software version using kexec - less than 5 seconds.
- Upgrade the switch FW by the new SONiC image if needed.
@@ -75,7 +75,7 @@ The restart of syncd docker should leave data plane intact until it starts again
Fast-reboot will finish successfully from a different NOS than SONiC with two possible scenarios:
- Dump files of default gateway, neighbors and fdb tables are provided to the new image in a format that meet the SONiC scheme, as SONiC does prior the reboot.
- - On this scenario all should work exacly the same as the switch rebooted from SONiC to SONiC.
+ - On this scenario all should work exactly the same as the switch rebooted from SONiC to SONiC.
- Dump files of default gateway, neighbors and fdb tables are not provided to the new image as SONiC does prior the reboot.
- On this scenario fast-reboot will finish successfully, but with low performance since all neighbors and fdb entries will be created by the slow path.
@@ -148,7 +148,7 @@ Same for FDB entries which will be created by the kernel as well, depends on the
When orchagent starts with the new SONiC image, the same infrastructure we use to reconcile fastfast-boot will start.
After INIT_VIEW and create_switch functions sent to syncd (reset of the ASIC took place here), 'warmRestoreAndSyncUp' will be executed.
This function will populate m_toSync with all tasks for syncd, by APP DB and CONFIG DB prior the reboot.
-To verify orchagent reached the same state as before the reboot, 'warmRestoreValidation' will verify no pending tasks left in the queue, meaning all proccessed succesfully and in the pipeline for syncd to configure the HW.
+To verify orchagent reached the same state as before the reboot, 'warmRestoreValidation' will verify no pending tasks left in the queue, meaning all processed successfully and in the pipeline for syncd to configure the HW.
At the end APPLY_VIEW will be sent to syncd to finalize the process, from this point orchagent enter the main loop and operates normally.
### NOTICE
@@ -161,7 +161,7 @@ This is solvable by the db migrator.
Syncd starts with the fast-reboot flag, trigger the ASIC reset when create_switch is requested from orchagent.
In addition, on this case temp view flag will set to false since it is not required, no comparison logic needed since current view is empty.
Basically INIT and APPLY view requests from orchagent are ignored by syncd, but bound the process from start to end.
-During reconsilations process of orchagent, syncd will recieve all tasks to restore the previous state.
+During reconsilations process of orchagent, syncd will receive all tasks to restore the previous state.
All other network applications will do the same as we do today for warm-reboot.
@@ -221,8 +221,8 @@ reboot-finalizer.sh (warm-finalizer.sh) script must also be templatized and upda
| /service/fast-shutdown/ | object | no | Fast reboot related properties. Used to generate the fast-reboot script. |
| /service/fast-shutdown/after | lits of strings | no | Same as for warm-shutdown. |
| /service/fast-shutdown/before | lits of strings | no | Same as for warm-shutdown. |
-| /processes | object | no | Processes infromation |
-| /processes/[name]/reconciles | boolean | no | Wether process performs warm-boot reconciliation, the warmboot-finalizer service has to wait for. Defaults to False. |
+| /processes | object | no | Processes information |
+| /processes/[name]/reconciles | boolean | no | Whether process performs warm-boot reconciliation, the warmboot-finalizer service has to wait for. Defaults to False. |
This chapter it taken from SONiC Application Extension Infrastructure HLD:
diff --git a/doc/fips/SONiC-OpenSSL-FIPS-140-3-deployment.md b/doc/fips/SONiC-OpenSSL-FIPS-140-3-deployment.md
index e722984b8ea..44d0e0e2652 100644
--- a/doc/fips/SONiC-OpenSSL-FIPS-140-3-deployment.md
+++ b/doc/fips/SONiC-OpenSSL-FIPS-140-3-deployment.md
@@ -10,7 +10,7 @@ Table of Contents
* [FIPS None Enforce Mode](#FIPS-None-Enforce-Mode)
* [FIPS Enforce Mode](#FIPS-Enforce-Mode)
* [SONiC FIPS State](#SONiC-FIPS-State)
-* [SONiC reboot and upgarde](#SONiC-reboot-and-upgarde)
+* [SONiC reboot and upgrade](#SONiC-reboot-and-upgrade)
* [SONiC warm-reboot or fast-reboot](#SONiC-warm-reboot-or-fast-reboot)
* [SONiC upgrade](#SONiC-upgrade)
* [Test cases](#Test-cases)
@@ -29,7 +29,7 @@ It is for the security requirement, the FIPS 140-3 feature should be enabled for
- Provide a way to enforce the FIPS for SONiC.
## Scopes
-1. The FIPS 140-3 is only availabel on SONiC OS Version 11 or above.
+1. The FIPS 140-3 is only available on SONiC OS Version 11 or above.
2. FIPS is supported on branches: 202205, 202211, master.
## SONiC Configuration for FIPS
@@ -95,7 +95,7 @@ The redis dictionary key is FIPS_STAT\|state.
GitHub Pull Request for reference: https://github.com/sonic-net/sonic-host-services/pull/69
-## SONiC reboot and upgarde
+## SONiC reboot and upgrade
### SONiC warm-reboot or fast-reboot
SONiC ware-reboot/fast-reboot will initialize the kernel command line, it only has impact when the FIPS enforcement flag changed, either from enforce to none-enforce, or from none-enforce to enforce.
diff --git a/doc/fips/SONiC-OpenSSL-FIPS-140-3.md b/doc/fips/SONiC-OpenSSL-FIPS-140-3.md
index ea42dfe527e..9ec88f4f709 100644
--- a/doc/fips/SONiC-OpenSSL-FIPS-140-3.md
+++ b/doc/fips/SONiC-OpenSSL-FIPS-140-3.md
@@ -111,7 +111,7 @@ Files in the packages:
Kerberos will use the builtin cryptographic module by default, but it allows to change the build option to use OpenSSl, see [MIT Kerberos features](https://web.mit.edu/kerberos/krb5-1.13/doc/mitK5features.html). SONiC will change the build option to use OpenSSL instead of the builtin one. It is not configurable to use the Kerberos builtin cryptographic module when OpenSSL used.
## Golang Cryptographic Module
-Golang has its own cryptographic module (see [crypto](https://github.com/golang/go/tree/master/src/crypto)) without FIPS supports. There are some branches with branch name starting with "dev.boringcrypto" (see [golang branches](https://github.com/golang/go/branches/all?query=dev.boringcrypto)), changing the Golang cryptographic APIs' referenece to use [BoringSSL](https://github.com/google/boringssl). Although BoringSSL is an open source project, but it used by Google only, not intened for general use.
+Golang has its own cryptographic module (see [crypto](https://github.com/golang/go/tree/master/src/crypto)) without FIPS supports. There are some branches with branch name starting with "dev.boringcrypto" (see [golang branches](https://github.com/golang/go/branches/all?query=dev.boringcrypto)), changing the Golang cryptographic APIs' reference to use [BoringSSL](https://github.com/google/boringssl). Although BoringSSL is an open source project, but it used by Google only, not intened for general use.
To support FIPS for Golang, RedHat offers an alternative solution (see [here](https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-hat-enterprise-linux)), it builds on top of the Golang's dev.bringcrypt branches, has ability to call into OpenSSL, not BoringSSL. SONiC can reuse the RedHat sulotion, one difference is that RedHat supports FIPS for OpenSSL directly, SONiC uses OpenSSL Engine.
@@ -123,7 +123,7 @@ When FIPS enabled, both of the BoringSSL Enable Option and the SymCrypt Enabled
## Application Impact
Some of functions of a application might be broken when using the cryptographic algorithms that are not FIPS compliant. It is relied on the tests of the applications to detect all the impact functions.
-For OpenSSH, Centos provides a [patch](https://git.centos.org/rpms/openssh/raw/c8/f/SOURCES/openssh-7.7p1-fips.patch) which is compiant with FIPS 140-2. We can apply the patch and verify if it can pass all the OpenSSH test cases when FIPS enabled.
+For OpenSSH, Centos provides a [patch](https://git.centos.org/rpms/openssh/raw/c8/f/SOURCES/openssh-7.7p1-fips.patch) which is compliant with FIPS 140-2. We can apply the patch and verify if it can pass all the OpenSSH test cases when FIPS enabled.
## SONiC FIPS Configuration
@@ -135,7 +135,7 @@ grep 'sonic_fips=1' /proc/cmdline
There is another parameter fips=1 supported for SymCrypt OpenSSL to enable FIPS. The parameter will enable the Linux Kernel FIPS, but the Linux Kernel FIPS is not supported yet, and it is out of scope in this document. In future, when the FIPS is supported by SONiC Linux Kernel, and the parameter fips=1 has already set, it is not necessary to set sonic_fips=1.
-For grub, one of implemetation as below:
+For grub, one of implementation as below:
cat /etc/grub.d/99-fips.cfg
```
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT sonic_fips=1"
@@ -174,7 +174,7 @@ Support to enable/disable the FIPS feature, the feature is enabled by default in
```
INCLUDE_FIPS ?= y
```
-Support to enable/disable FIPS config, the flage is disabled by default. IF the option is set, then the fips is enabled by default in the image, not necesary to do the config in system level or application level.
+Support to enable/disable FIPS config, the flags is disabled by default. IF the option is set, then the fips is enabled by default in the image, not necessary to do the config in system level or application level.
```
ENABLE_FIPS ?= n
```
diff --git a/doc/fips/SONiC-SAI-POST.md b/doc/fips/SONiC-SAI-POST.md
index a89847038b2..41ca320665b 100644
--- a/doc/fips/SONiC-SAI-POST.md
+++ b/doc/fips/SONiC-SAI-POST.md
@@ -8,7 +8,7 @@
## Table of Contents
* [Overview](#Overview)
* [Design requirements](#Design-requirements)
-* [Deisgn details](#Design-details)
+* [Design details](#Design-details)
* [State DB](#State-DB)
* [Enabling POST in SAI switch init](#Enabling-POST-in-SAI-switch-init)
* [Enabling POST in SAI MACSec init](#Enabling-POST-in-SAI-MACSec-init)
@@ -28,7 +28,7 @@ The design must meet the following requirements:
- POST failure must not affect the operation of non-MACSec ports.
- Explicit visibility must be provided if POST fails, for example, in syslog. The syslog message must include the details of the failure. For example, SAI object Id of ports that fail POST and the corresponding MACSec engine.
-## Deisgn details
+## Design details
The following figure depicts the data flow and SONiC components in the design. Orchagent is responsible for triggering POST via SAI calls and publishing POST status in State DB. MACSec container, precisely MACSecMgr, is enhanced to be POST aware and only process MACSec configuration after POST has passed.
@@ -85,7 +85,7 @@ Since SAI supports POST completion callback, a callback or notification function
If SAI POST fails, MACSecOrch reads POST status of all MACSec ports and finds out which port has failed in POST. MACSecOrch then adds the details of the failure in syslog. The following syslog is added to report SAI POST failure.
-Swith level POST failure
+Switch level POST failure
```
Switch MACSec POST failed
```
diff --git a/doc/fwutil/fwutil.md b/doc/fwutil/fwutil.md
index 11ca4266f3f..b6e960cefdf 100755
--- a/doc/fwutil/fwutil.md
+++ b/doc/fwutil/fwutil.md
@@ -334,7 +334,7 @@ Chassis1 N/A CPLD