-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SONiC QoS MAPs and PORT_QOS_MAP Yang #7375
Conversation
} | ||
|
||
list DSCP_TO_TC_MAP { //this is list inside list for storing mapping between two fields | ||
key "dscp tc_num"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed in the community meeting today (May-13), please get back to us whether you are going to change the QOS backend to support the yang model for DSCP_TO_TC_MAP_LIST. Like we discussed, nested-list (list-inside-list) can't be supported for the current QOS-backend DB contents expectation. More details below.
With current QOS backend code's DB expectation, we can't represent that in yang-format for the inner list (DSCP_TO_TC_MAP) using nested list (list-inside-list) with keys being dscp & tc_num. As shown below in Redis DB, dot1p & tc_num shouldn't go to key-portion, instead it should go to feild/value portion. Table below has db representation for clarity. Current QOS backend expectation.
To solve, either we should change the QOS backend to accept flat-table as like other tables instead of nested-list. Here the 2nd list can be separated out as an independent list with "map-name" (parent-key with leaf-ref) and DSCP as key with tc_num as mandatory leaf. Or the other approach is to introduce the sonic-extensions we proposed earlier (map-list & map-leaf) to take of writing these special yang cases to DB as expected by current QOS backend.
Same problem exists for DOT1P_TO_TC_MAP
as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each DSCP is mapped to only 1 TC, so we can use only DSCP as key. If both fields are keys, that makes 24:3 and 24:4 a valid combination.
} | ||
|
||
list DOT1P_TO_TC_MAP { //this is list inside list for storing mapping between two fields | ||
key "dot1p tc_num"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem mentioned below for DSCP_TO_TC_MAP exists for DOT1P_TO_TC_MAP as well.
Hi @praveen-li - please confirm QOS backend change approach and please share with the team. |
|
||
"DSCP_TO_TC_MAP": { | ||
"Dscp_to_tc_map1": { | ||
"24": "3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This representation is different than other lists, I think in future we should change it as below, so that the translation code is not burdened by special cases: @lguohan @renukamanavalan for comment.
"DSCP_TO_TC_MAP": {
"Dscp_to_tc_map1": {
"24": {
"tc_num": "3"
}
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does the redis entry looks like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like exactly like line 693: "24": "3", in which "24" is the field name, "3" is the value.
depends on another PR which @AshokDaparthi will add the link here. |
depends on sonic-net/sonic-utilities#1626 |
sonic-net/sonic-utilities#1626 is merged |
depends on #8683 |
depends on sonic-net/sonic-swss#1754 as well |
Need close the dependent PRs before moving forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PFC_PRIORITY_TO_PRIORITY_GROUP_MAP
should also be defined here, right?
|
||
leaf pfc_priority { | ||
type string { | ||
pattern "[0-9]?"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pfc_priority
should be in range [0-7]
?
@ohu1 There are few unresolved comments, can you address them. |
'./yang-models/sonic-tc-dot1p-map.yang', | ||
'./yang-models/sonic-tc-priority-group-map.yang', | ||
'./yang-models/sonic-tc-queue-map.yang', | ||
'./yang-models/sonic-pfc-priority-queue-map.yang', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smaheshs - We have not done this because PORT_QOS_MAP is reference to maps. I will raise it once format changes are merged.
ee254d7
to
638e64f
Compare
@praveen-li - As per last discussion i remember, you are adding special handling in libyang for handling nested list. Can you confirm this is done or not? |
Azure/sonic-swss#1754 is merged |
638e64f
to
189aeb5
Compare
@praveen-li would you please help to share your comments? |
@AshokDaparthi will follow-up based on the discussion in today's meeting. |
proceed with current implementation, nested list can be added later as long term solution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the PR description to reflect all the tables added as part of this PR. Also I do not see testcases added for these changes.
There is also a 'PFC_PRIORITY_TO_PRIORITY_GROUP_MAP' table used by some vendors which is missing here. Is there a way to add a constraint based on the asic type in yang?
src/sonic-yang-models/yang-models/sonic-pfc-priority-queue-map.yang
Outdated
Show resolved
Hide resolved
@neethajohn - This PR is work in Progress. sonic-ext for qos-map will be removed because it not supported in python validation code. I am looking at infra code changes needed in python validator for qos map(nested list). If we think it will take time and not much advantage we will modify yang as flat model like discussed in last call. based on yang i will write test cases. |
@neethajohn @praveen-li - Added test cases. Please review. |
This pull request introduces 2 alerts when merging f55687389964d9d2336c03f48af93996b2152e84 into c374705 - view on LGTM.com new alerts:
|
add dot1p-tc, pfc-pg, tc-dot1p, tc-dscp, tc-pg, tc-queue maps
This pull request introduces 2 alerts when merging fb9c26a2f3c09e43e5739316b9ebf6f4572c4a55 into a99d78d - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, we can merge it after test passes. Thx.
@neethajohn , @smaheshm - Can you re-approve and merge. |
@smaheshm - Can you merge this |
This reverts commit 459d3d1.
This reverts commit 9c172a5.
…ernal branch Related work items: sonic-net#525, sonic-net#534, sonic-net#909, sonic-net#927, sonic-net#930, sonic-net#934, sonic-net#935, sonic-net#937, sonic-net#938, sonic-net#939, sonic-net#940, sonic-net#943, sonic-net#944, sonic-net#945, sonic-net#946, sonic-net#948, sonic-net#1702, sonic-net#1923, sonic-net#1936, sonic-net#1942, sonic-net#2315, sonic-net#7281, sonic-net#7375, sonic-net#8659, sonic-net#8799, sonic-net#8868, sonic-net#8875, sonic-net#8935, sonic-net#8942, sonic-net#8956, sonic-net#8961, sonic-net#8966, sonic-net#8969, sonic-net#8971, sonic-net#8978, sonic-net#8991, sonic-net#8996, sonic-net#9001, sonic-net#9008, #3146150
#### What I did Fixes #2034 Which lists where handled before in ConfigDb to YANG conversion? - Dictionary of key to Object e.g. ``` "TACPLUS_SERVER": { "1.1.1.1": { <= Key: Object (i.e. {...}) "priority": "1", "tcp_port": "49" }, "1.1.1.2": { "priority": "1", "tcp_port": "49" }, "1.1.1.3": { "priority": "1", "tcp_port": "49" } } ``` - List of values ``` "VLAN": { "Vlan1000": { "vlanid": "1000", "dhcp_servers": [ <= Values "192.0.0.1", "192.0.0.2", "192.0.0.3", "192.0.0.4" ] } } ``` - But there is no handling of Dictionary of Key to Value ``` "DOT1P_TO_TC_MAP": { "Dot1p_to_tc_map1": { <= Key: Value "1": "1", "2": "2", "3": "1", "4": "2" } }, ``` Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang. After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath. Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests. #### How I did it When handling a list, check if it is of type1. If that's the case call type1 list handling. #### How to verify it unit-test #### Previous command output (if the output of a command-line utility has changed) #### New command output (if the output of a command-line utility has changed)
#### What I did Fixes #2034 Which lists where handled before in ConfigDb to YANG conversion? - Dictionary of key to Object e.g. ``` "TACPLUS_SERVER": { "1.1.1.1": { <= Key: Object (i.e. {...}) "priority": "1", "tcp_port": "49" }, "1.1.1.2": { "priority": "1", "tcp_port": "49" }, "1.1.1.3": { "priority": "1", "tcp_port": "49" } } ``` - List of values ``` "VLAN": { "Vlan1000": { "vlanid": "1000", "dhcp_servers": [ <= Values "192.0.0.1", "192.0.0.2", "192.0.0.3", "192.0.0.4" ] } } ``` - But there is no handling of Dictionary of Key to Value ``` "DOT1P_TO_TC_MAP": { "Dot1p_to_tc_map1": { <= Key: Value "1": "1", "2": "2", "3": "1", "4": "2" } }, ``` Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang. After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath. Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests. #### How I did it When handling a list, check if it is of type1. If that's the case call type1 list handling. #### How to verify it unit-test #### Previous command output (if the output of a command-line utility has changed) #### New command output (if the output of a command-line utility has changed)
#### What I did Fixes #2034 Which lists where handled before in ConfigDb to YANG conversion? - Dictionary of key to Object e.g. ``` "TACPLUS_SERVER": { "1.1.1.1": { <= Key: Object (i.e. {...}) "priority": "1", "tcp_port": "49" }, "1.1.1.2": { "priority": "1", "tcp_port": "49" }, "1.1.1.3": { "priority": "1", "tcp_port": "49" } } ``` - List of values ``` "VLAN": { "Vlan1000": { "vlanid": "1000", "dhcp_servers": [ <= Values "192.0.0.1", "192.0.0.2", "192.0.0.3", "192.0.0.4" ] } } ``` - But there is no handling of Dictionary of Key to Value ``` "DOT1P_TO_TC_MAP": { "Dot1p_to_tc_map1": { <= Key: Value "1": "1", "2": "2", "3": "1", "4": "2" } }, ``` Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang. After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath. Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests. #### How I did it When handling a list, check if it is of type1. If that's the case call type1 list handling. #### How to verify it unit-test #### Previous command output (if the output of a command-line utility has changed) #### New command output (if the output of a command-line utility has changed)
#### What I did Fixes #2034 Which lists where handled before in ConfigDb to YANG conversion? - Dictionary of key to Object e.g. ``` "TACPLUS_SERVER": { "1.1.1.1": { <= Key: Object (i.e. {...}) "priority": "1", "tcp_port": "49" }, "1.1.1.2": { "priority": "1", "tcp_port": "49" }, "1.1.1.3": { "priority": "1", "tcp_port": "49" } } ``` - List of values ``` "VLAN": { "Vlan1000": { "vlanid": "1000", "dhcp_servers": [ <= Values "192.0.0.1", "192.0.0.2", "192.0.0.3", "192.0.0.4" ] } } ``` - But there is no handling of Dictionary of Key to Value ``` "DOT1P_TO_TC_MAP": { "Dot1p_to_tc_map1": { <= Key: Value "1": "1", "2": "2", "3": "1", "4": "2" } }, ``` Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang. After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath. Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests. #### How I did it When handling a list, check if it is of type1. If that's the case call type1 list handling. #### How to verify it unit-test #### Previous command output (if the output of a command-line utility has changed) #### New command output (if the output of a command-line utility has changed)
Why I did it
Created SONiC Yang model for the following QOS MAPs and PORT QOS MAP:
DSCP_TO_TC_MAP
DOT1P_TO_TC_MAP
TC_TO_QUEUE_MAP
TC_TO_PRIORITY_GROUP_MAP
MAP_PFC_PRIORITY_TO_QUEUE
PORT_QOS_MAP
How I did it
Defined Yang models for QOS MAPs based on Guideline doc:
https://github.com/Azure/SONiC/blob/master/doc/mgmt/SONiC_YANG_Model_Guidelines.md
and
https://github.com/Azure/sonic-utilities/blob/master/doc/Command-Reference.md
How to verify it
sonic_yang_models package build
The infra code was modified to handle the nested list definition in YANG and translate it to a flat list in DB.
Which release branch to backport (provide reason below if selected)
Description for the changelog