fix the type for SAI_BUFFER_PROFILE_ATTR_BUFFER_SIZE #1942
Merged
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 <alpesh@cisco.com>
prsunny
approved these changes
Oct 7, 2021
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
stephenxs
approved these changes
Oct 8, 2021
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Hello Prince, |
qiluo-msft
pushed a commit
that referenced
this pull request
Nov 24, 2021
Fixing the type for SAI_BUFFER_PROFILE_ATTR_BUFFER_SIZE It is incorrectly set to u32 and is not clearing the higher 32 bits in the union Sample code: attr.id = SAI_BUFFER_PROFILE_ATTR_POOL_ID; attr.value.oid = getPool(ingress); <<<<-- the higher order 32 bits were retrieved for BUFFER_PROFILE_ATTR_BUFFER_SIZE attribs.push_back(attr); attr.id = SAI_BUFFER_PROFILE_ATTR_THRESHOLD_MODE; attr.value.u32 = SAI_BUFFER_PROFILE_THRESHOLD_MODE_DYNAMIC; attribs.push_back(attr); attr.id = SAI_BUFFER_PROFILE_ATTR_BUFFER_SIZE; attr.value.u64 = 0; <<<<-------------------------------- This was u32 earlier attribs.push_back(attr); Signed-off-by: Alpesh S Patel alpesh@cisco.com What I did Change the attribute value type from u32 to u64 as in SAI header file - https://github.com/opencomputeproject/SAI/blob/v1.7/inc/saibuffer.h /** * @brief Reserved buffer size in bytes * * @type sai_uint64_t * @flags MANDATORY_ON_CREATE | CREATE_AND_SET */ SAI_BUFFER_PROFILE_ATTR_RESERVED_BUFFER_SIZE, /** @ignore - for backward compatibility */ SAI_BUFFER_PROFILE_ATTR_BUFFER_SIZE = SAI_BUFFER_PROFILE_ATTR_RESERVED_BUFFER_SIZE, Why I did it since u32 was getting set and the actual data type is u64, at SAI layer, when the value is retrieved as u64, the upper 32 bits are read from the previously written attribute value (pool oid) How I verified it Made this change in sonic and verified it on the hardware platform via debug and correct operation
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 <alpesh@cisco.com>
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 <alpesh@cisco.com>
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
What I did Add show command for BFD sessions. How I did it Add show command for BFD session and unit tests. How to verify it Verify the show command locally and unit test passes.
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 <alpesh@cisco.com>
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.
Fixing the type for SAI_BUFFER_PROFILE_ATTR_BUFFER_SIZE
It is incorrectly set to u32 and is not clearing the higher 32 bits in the union
Sample code:
Signed-off-by: Alpesh S Patel alpesh@cisco.com
What I did
Change the attribute value type from u32 to u64 as in SAI header file - https://github.com/opencomputeproject/SAI/blob/v1.7/inc/saibuffer.h
Why I did it
since u32 was getting set and the actual data type is u64, at SAI layer, when the value is retrieved as u64, the upper 32 bits are read from the previously written attribute value (pool oid)
How I verified it
Made this change in sonic and verified it on the hardware platform via debug and correct operation
Details if related