[sonic-swss]:enable unconfiguring PFC on last TC on a port #1962
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Alpesh S Patel <[email protected]>
prsunny
reviewed
Oct 15, 2021
neethajohn
reviewed
Oct 22, 2021
Signed-off-by: Alpesh S Patel <[email protected]>
|
|
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@neethajohn some tests are failing. I checked to verify that the test I added is passing. This patch needs to be merged in master branch too. Let me know if any further action is required on my part. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@prsunny Thanks for running the pipelines again. I see that the required checks have passed, let me know if you have any other comments on the PR. |
neethajohn
approved these changes
Nov 9, 2021
|
Hi @abdosi , please help with double commit to 202012. Thanks |
qiluo-msft
pushed a commit
that referenced
this pull request
Nov 24, 2021
* enable unconfiguring PFC on last TC on a port Signed-off-by: Alpesh S Patel <[email protected]>
|
Hi @qiluo-msft , Thanks for including this in 202012. May we also release this ref point to Azure/Sonic-buildimage 202012 branch to include this fix. Thanks |
|
Please submit a submodule PR for buildimage 202012 branch. |
yxieca
pushed a commit
that referenced
this pull request
Dec 17, 2021
What I did Enables support for Rx traffic drop for a port/tc by applying the zero buffer profile Changed class hierarchy so that default getHwCounters() function is used (since the Rx counter support is enabled) Fixes a pfc-wd off by 1 detection in case of PFC-WD detection without traffic Why I did it enabling a missing functionality leveraging sonic code as our sdk now implements the missing counter fixes a bug How I verified it on a cisco-8000 router: detected pfc-wd detection and restore happens within the (detection/restore-time + 1 poll interval) duration and that the changeset passes MSFT tests Verified that when PFC-WD is detected, both Rx and Tx traffic for a port/tc is dropped and no forwarding happens Details if related this patch will need to be double committed to the 202012 branch along with #1942 , #1748 and #1962 Signed-off-by: Alpesh S Patel <[email protected]>
qiluo-msft
pushed a commit
that referenced
this pull request
Dec 20, 2021
What I did Enables support for Rx traffic drop for a port/tc by applying the zero buffer profile Changed class hierarchy so that default getHwCounters() function is used (since the Rx counter support is enabled) Fixes a pfc-wd off by 1 detection in case of PFC-WD detection without traffic Why I did it enabling a missing functionality leveraging sonic code as our sdk now implements the missing counter fixes a bug How I verified it on a cisco-8000 router: detected pfc-wd detection and restore happens within the (detection/restore-time + 1 poll interval) duration and that the changeset passes MSFT tests Verified that when PFC-WD is detected, both Rx and Tx traffic for a port/tc is dropped and no forwarding happens Details if related this patch will need to be double committed to the 202012 branch along with #1942 , #1748 and #1962 Signed-off-by: Alpesh S Patel <[email protected]>
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
…LOOPBACK_INTERFACE/LOOPBACK#/vrf_name as create-only (sonic-net#1969) #### What I did Fix sonic-net#1962 Updated `create-only` flag meaning. From, Field is not replaceable but can be added or deleted. In other words: - Field can be added - Field can be deleted - Field cannot be replaced To, Field is only created, but never modified/updated. In other words: - Field cannot be added, only if the parent is added - Field cannot be deleted, only if the parent is deleted - Field cannot be replaced Also marked `/LOOPBACK_INTERFACE/LOOPBACK#/vrf_name` as `create-only` #### How I did it - Field was already not replaceable -- so no changes - If field is added, but parent already exist -- fail create-only validation - If field is deleted, but parent remain -- fail create-only validation #### How to verify it unit-test #### Examples Check issue to see how `apply-patch` behaved before this fix. Each example below we show configdb, vrf_01, vrf_02, and ip interfaces before and after the update. **Adding vrf_name** ```sh admin@vlab-01:~/lo$ show run all | grep -i 'loopback0\|vrf_01' -a3 } }, "LOOPBACK_INTERFACE": { "Loopback0": {}, "Loopback0|10.1.0.32/32": {}, "Loopback0|FC00:1::32/128": {} }, "MAP_PFC_PRIORITY_TO_QUEUE": { "AZURE": { -- } }, "VRF": { "Vrf_01": {}, "Vrf_02": {} }, "WRED_PROFILE": { admin@vlab-01:~/lo$ show ip route vrf Vrf_01 admin@vlab-01:~/lo$ show ip route vrf Vrf_02 admin@vlab-01:~/lo$ show ip interfaces | grep -i loopback0 Loopback0 10.1.0.32/32 up/up N/A N/A admin@vlab-01:~/lo$ sudo config apply-patch add-lo0-vrf01.json-patch -i /BGP_NEIGHBOR -i /DEVICE_METADATA -i /FEATURE -i /FLEX_COUNTER_TABLE -i /VLAN/Vlan1000/members -i /SCHEDULER -i /QUEUE Patch Applier: Patch application starting. Patch Applier: Patch: [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0/vrf_name", "value": "Vrf_01"}] Patch Applier: Getting current config db. Patch Applier: Simulating the target full config after applying the patch. Patch Applier: Validating target config does not have empty tables, since they do not show up in ConfigDb. Patch Applier: Sorting patch updates. Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, libyang[0]: Must condition "(current() = ../../LOOPBACK_INTERFACE_LIST[name=current()]/name)" not satisfied. (path: /sonic-loopback-interface:sonic-loopback-interface/LOOPBACK_INTERFACE/LOOPBACK_INTERFACE_IPPREFIX_LIST[name='Loopback0'][ip-prefix='10.1.0.32/32']/name) libyang[0]: Must condition not satisfied, Try adding lo<>: {}, Example: 'lo1': {} (path: /sonic-loopback-interface:sonic-loopback-interface/LOOPBACK_INTERFACE/LOOPBACK_INTERFACE_IPPREFIX_LIST[name='Loopback0'][ip-prefix='10.1.0.32/32']/name) sonic_yang(3):Data Loading Failed:Must condition not satisfied, Try adding lo<>: {}, Example: 'lo1': {} Patch Applier: The patch was sorted into 4 changes: Patch Applier: * [{"op": "remove", "path": "/LOOPBACK_INTERFACE"}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE", "value": {"Loopback0": {"vrf_name": "Vrf_01"}}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|10.1.0.32~132", "value": {}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|FC00:1::32~1128", "value": {}}] Patch Applier: Applying 4 changes in order: Patch Applier: * [{"op": "remove", "path": "/LOOPBACK_INTERFACE"}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE", "value": {"Loopback0": {"vrf_name": "Vrf_01"}}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|10.1.0.32~132", "value": {}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|FC00:1::32~1128", "value": {}}] Patch Applier: Verifying patch updates are reflected on ConfigDB. Patch Applier: Patch application completed. Patch applied successfully. admin@vlab-01:~/lo$ show run all | grep -i 'loopback0\|vrf_01' -a3 } }, "LOOPBACK_INTERFACE": { "Loopback0": { "vrf_name": "Vrf_01" }, "Loopback0|10.1.0.32/32": {}, "Loopback0|FC00:1::32/128": {} }, "MAP_PFC_PRIORITY_TO_QUEUE": { "AZURE": { -- } }, "VRF": { "Vrf_01": {}, "Vrf_02": {} }, "WRED_PROFILE": { admin@vlab-01:~/lo$ show ip route vrf Vrf_01 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup VRF Vrf_01: C>* 10.1.0.32/32 is directly connected, Loopback0, 00:00:19 admin@vlab-01:~/lo$ show ip route vrf Vrf_02 admin@vlab-01:~/lo$ show ip interfaces | grep -i loopback0 Loopback0 Vrf_01 10.1.0.32/32 up/up N/A N/A admin@vlab-01:~/lo$ ``` **Replacing vrf_name** ```sh admin@vlab-01:~/lo$ show run all | grep -i 'loopback0\|vrf_01' -a3 } }, "LOOPBACK_INTERFACE": { "Loopback0": { "vrf_name": "Vrf_01" }, "Loopback0|10.1.0.32/32": {}, "Loopback0|FC00:1::32/128": {} }, "MAP_PFC_PRIORITY_TO_QUEUE": { "AZURE": { -- } }, "VRF": { "Vrf_01": {}, "Vrf_02": {} }, "WRED_PROFILE": { admin@vlab-01:~/lo$ show ip route vrf Vrf_01 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup VRF Vrf_01: C>* 10.1.0.32/32 is directly connected, Loopback0, 00:00:19 admin@vlab-01:~/lo$ show ip route vrf Vrf_02 admin@vlab-01:~/lo$ show ip interfaces | grep -i loopback0 Loopback0 Vrf_01 10.1.0.32/32 up/up N/A N/A admin@vlab-01:~/lo$ sudo config apply-patch replace-lo0-vrf02.json-patch -i /BGP_NEIGHBOR -i /DEVICE_METADATA -i /FEATURE -i /FLEX_COUNTER_TABLE -i /VLAN/Vlan1000/members -i /SCHEDULER -i /QUEUE Patch Applier: Patch application starting. Patch Applier: Patch: [{"op": "replace", "path": "/LOOPBACK_INTERFACE/Loopback0/vrf_name", "value": "Vrf_02"}] Patch Applier: Getting current config db. Patch Applier: Simulating the target full config after applying the patch. Patch Applier: Validating target config does not have empty tables, since they do not show up in ConfigDb. Patch Applier: Sorting patch updates. Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, libyang[0]: Must condition "(current() = ../../LOOPBACK_INTERFACE_LIST[name=current()]/name)" not satisfied. (path: /sonic-loopback-interface:sonic-loopback-interface/LOOPBACK_INTERFACE/LOOPBACK_INTERFACE_IPPREFIX_LIST[name='Loopback0'][ip-prefix='10.1.0.32/32']/name) libyang[0]: Must condition not satisfied, Try adding lo<>: {}, Example: 'lo1': {} (path: /sonic-loopback-interface:sonic-loopback-interface/LOOPBACK_INTERFACE/LOOPBACK_INTERFACE_IPPREFIX_LIST[name='Loopback0'][ip-prefix='10.1.0.32/32']/name) sonic_yang(3):Data Loading Failed:Must condition not satisfied, Try adding lo<>: {}, Example: 'lo1': {} Patch Applier: The patch was sorted into 4 changes: Patch Applier: * [{"op": "remove", "path": "/LOOPBACK_INTERFACE"}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE", "value": {"Loopback0": {"vrf_name": "Vrf_02"}}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|10.1.0.32~132", "value": {}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|FC00:1::32~1128", "value": {}}] Patch Applier: Applying 4 changes in order: Patch Applier: * [{"op": "remove", "path": "/LOOPBACK_INTERFACE"}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE", "value": {"Loopback0": {"vrf_name": "Vrf_02"}}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|10.1.0.32~132", "value": {}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|FC00:1::32~1128", "value": {}}] Patch Applier: Verifying patch updates are reflected on ConfigDB. Patch Applier: Patch application completed. Patch applied successfully. admin@vlab-01:~/lo$ show run all | grep -i 'loopback0\|vrf_01' -a3 } }, "LOOPBACK_INTERFACE": { "Loopback0": { "vrf_name": "Vrf_02" }, "Loopback0|10.1.0.32/32": {}, "Loopback0|FC00:1::32/128": {} }, "MAP_PFC_PRIORITY_TO_QUEUE": { "AZURE": { -- } }, "VRF": { "Vrf_01": {}, "Vrf_02": {} }, "WRED_PROFILE": { admin@vlab-01:~/lo$ show ip route vrf Vrf_01 admin@vlab-01:~/lo$ show ip route vrf Vrf_02 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup VRF Vrf_02: C>* 10.1.0.32/32 is directly connected, Loopback0, 00:00:29 admin@vlab-01:~/lo$ show ip interfaces | grep -i loopback0 Loopback0 Vrf_02 10.1.0.32/32 up/up N/A N/A admin@vlab-01:~/lo$ ``` **Removing vrf_name** ```sh admin@vlab-01:~/lo$ show run all | grep -i 'loopback0\|vrf_01' -a3 } }, "LOOPBACK_INTERFACE": { "Loopback0": { "vrf_name": "Vrf_02" }, "Loopback0|10.1.0.32/32": {}, "Loopback0|FC00:1::32/128": {} }, "MAP_PFC_PRIORITY_TO_QUEUE": { "AZURE": { -- } }, "VRF": { "Vrf_01": {}, "Vrf_02": {} }, "WRED_PROFILE": { admin@vlab-01:~/lo$ show ip route vrf Vrf_01 admin@vlab-01:~/lo$ show ip route vrf Vrf_02 Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup VRF Vrf_02: C>* 10.1.0.32/32 is directly connected, Loopback0, 00:00:29 admin@vlab-01:~/lo$ show ip interfaces | grep -i loopback0 Loopback0 Vrf_02 10.1.0.32/32 up/up N/A N/A admin@vlab-01:~/lo$ sudo config apply-patch remove-lo0-vrf02.json-patch -i /BGP_NEIGHBOR -i /DEVICE_METADATA -i /FEATURE -i /FLEX_COUNTER_TABLE -i /VLAN/Vlan1000/members -i /SCHEDULER -i /QUEUE Patch Applier: Patch application starting. Patch Applier: Patch: [{"op": "remove", "path": "/LOOPBACK_INTERFACE/Loopback0/vrf_name"}] Patch Applier: Getting current config db. Patch Applier: Simulating the target full config after applying the patch. Patch Applier: Validating target config does not have empty tables, since they do not show up in ConfigDb. Patch Applier: Sorting patch updates. Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, Note: Below table(s) have no YANG models: BGP_PEER_RANGE, CABLE_LENGTH, CONSOLE_SWITCH, DEVICE_NEIGHBOR_METADATA, DHCP_SERVER, KDUMP, RESTAPI, SNMP, SNMP_COMMUNITY, SYSLOG_SERVER, TELEMETRY, libyang[0]: Must condition "(current() = ../../LOOPBACK_INTERFACE_LIST[name=current()]/name)" not satisfied. (path: /sonic-loopback-interface:sonic-loopback-interface/LOOPBACK_INTERFACE/LOOPBACK_INTERFACE_IPPREFIX_LIST[name='Loopback0'][ip-prefix='10.1.0.32/32']/name) libyang[0]: Must condition not satisfied, Try adding lo<>: {}, Example: 'lo1': {} (path: /sonic-loopback-interface:sonic-loopback-interface/LOOPBACK_INTERFACE/LOOPBACK_INTERFACE_IPPREFIX_LIST[name='Loopback0'][ip-prefix='10.1.0.32/32']/name) sonic_yang(3):Data Loading Failed:Must condition not satisfied, Try adding lo<>: {}, Example: 'lo1': {} Patch Applier: The patch was sorted into 4 changes: Patch Applier: * [{"op": "remove", "path": "/LOOPBACK_INTERFACE"}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE", "value": {"Loopback0": {}}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|10.1.0.32~132", "value": {}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|FC00:1::32~1128", "value": {}}] Patch Applier: Applying 4 changes in order: Patch Applier: * [{"op": "remove", "path": "/LOOPBACK_INTERFACE"}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE", "value": {"Loopback0": {}}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|10.1.0.32~132", "value": {}}] Patch Applier: * [{"op": "add", "path": "/LOOPBACK_INTERFACE/Loopback0|FC00:1::32~1128", "value": {}}] Patch Applier: Verifying patch updates are reflected on ConfigDB. Patch Applier: Patch application completed. Patch applied successfully. admin@vlab-01:~/lo$ show run all | grep -i 'loopback0\|vrf_01' -a3 } }, "LOOPBACK_INTERFACE": { "Loopback0": {}, "Loopback0|10.1.0.32/32": {}, "Loopback0|FC00:1::32/128": {} }, "MAP_PFC_PRIORITY_TO_QUEUE": { "AZURE": { -- } }, "VRF": { "Vrf_01": {}, "Vrf_02": {} }, "WRED_PROFILE": { admin@vlab-01:~/lo$ show ip route vrf Vrf_01 admin@vlab-01:~/lo$ show ip route vrf Vrf_02 admin@vlab-01:~/lo$ show ip interfaces | grep -i loopback0 Loopback0 10.1.0.32/32 up/up N/A N/A admin@vlab-01:~/lo$ ```
preetham-singh
pushed a commit
to preetham-singh/sonic-swss
that referenced
this pull request
Aug 6, 2022
…00 (sonic-net#2041) What I did Enables support for Rx traffic drop for a port/tc by applying the zero buffer profile Changed class hierarchy so that default getHwCounters() function is used (since the Rx counter support is enabled) Fixes a pfc-wd off by 1 detection in case of PFC-WD detection without traffic Why I did it enabling a missing functionality leveraging sonic code as our sdk now implements the missing counter fixes a bug How I verified it on a cisco-8000 router: detected pfc-wd detection and restore happens within the (detection/restore-time + 1 poll interval) duration and that the changeset passes MSFT tests Verified that when PFC-WD is detected, both Rx and Tx traffic for a port/tc is dropped and no forwarding happens Details if related this patch will need to be double committed to the 202012 branch along with sonic-net#1942 , sonic-net#1748 and sonic-net#1962 Signed-off-by: Alpesh S Patel <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Alpesh S Patel [email protected]
What I did
Added code to enable disabling PFC from the single TC that is configured on a port.
Why I did it
Currently if a single TC is configured on a port, it cannot be unconfigured by setting the pfc bitmask to 0.
The if (pfc_enable) check skips as pfc_enable bit pattern is 0
This code change adds ability to unconfigure PFC on a single TC that's configured on a port.
How I verified it
tested it on a cisco-8000 router running sonic image.
Details if related
Note to committer: This also needs to go into 202012 version of the branch.