Skip to content
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

Merged
merged 5 commits into from
Oct 19, 2021
Merged

Conversation

ohu1
Copy link
Contributor

@ohu1 ohu1 commented Apr 20, 2021

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)

  • 201811
  • 201911
  • 202006
  • 202012

Description for the changelog

@ohu1 ohu1 requested a review from lguohan as a code owner April 20, 2021 00:15
@ghost
Copy link

ghost commented Apr 20, 2021

CLA assistant check
All CLA requirements met.

@lguohan lguohan added the YANG YANG model related changes label Apr 20, 2021
}

list DSCP_TO_TC_MAP { //this is list inside list for storing mapping between two fields
key "dscp tc_num";
Copy link
Collaborator

@rathnasabapathyv rathnasabapathyv May 13, 2021

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.

image

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

Copy link
Collaborator

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";
Copy link
Collaborator

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.

@anshuv-mfst
Copy link

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",
Copy link
Collaborator

@praveen-li praveen-li Jun 17, 2021

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"
           }
      }
 }

Copy link
Collaborator

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?

Copy link
Contributor Author

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.

@zhangyanzhao
Copy link
Collaborator

depends on another PR which @AshokDaparthi will add the link here.

@zhangyanzhao
Copy link
Collaborator

depends on sonic-net/sonic-utilities#1626

@zhangyanzhao
Copy link
Collaborator

sonic-net/sonic-utilities#1626 is merged

@zhangyanzhao
Copy link
Collaborator

depends on #8683

@zhangyanzhao
Copy link
Collaborator

depends on sonic-net/sonic-swss#1754 as well

@zhangyanzhao
Copy link
Collaborator

Need close the dependent PRs before moving forward.

Copy link
Collaborator

@stephenxs stephenxs left a 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]?";
Copy link
Collaborator

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]?

@smaheshm
Copy link
Contributor

@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',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see yang model for PORT_QOS_MAP (unless I missed it). Is there a separate PR for it.

image

Copy link
Contributor

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.

@AshokDaparthi
Copy link
Contributor

@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?

@zhangyanzhao
Copy link
Collaborator

depends on Azure/sonic-swss#1754 as well

Azure/sonic-swss#1754 is merged

@zhangyanzhao
Copy link
Collaborator

@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?

@praveen-li would you please help to share your comments?

@zhangyanzhao
Copy link
Collaborator

@AshokDaparthi will follow-up based on the discussion in today's meeting.

@zhangyanzhao
Copy link
Collaborator

proceed with current implementation, nested list can be added later as long term solution.

Copy link
Contributor

@neethajohn neethajohn left a 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-dot1p-tc-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-tc-dot1p-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-tc-dscp-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-dot1p-tc-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-port-qos-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-port-qos-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-port-qos-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-port-qos-map.yang Outdated Show resolved Hide resolved
src/sonic-yang-models/yang-models/sonic-port-qos-map.yang Outdated Show resolved Hide resolved
@AshokDaparthi
Copy link
Contributor

@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.

@AshokDaparthi
Copy link
Contributor

@neethajohn @praveen-li - Added test cases. Please review.

@lgtm-com
Copy link

lgtm-com bot commented Oct 15, 2021

This pull request introduces 2 alerts when merging f55687389964d9d2336c03f48af93996b2152e84 into c374705 - view on LGTM.com

new alerts:

  • 2 for Unused local variable

@lgtm-com
Copy link

lgtm-com bot commented Oct 18, 2021

This pull request introduces 2 alerts when merging fb9c26a2f3c09e43e5739316b9ebf6f4572c4a55 into a99d78d - view on LGTM.com

new alerts:

  • 2 for Unused local variable

Copy link
Collaborator

@praveen-li praveen-li left a 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.

@AshokDaparthi
Copy link
Contributor

@neethajohn , @smaheshm - Can you re-approve and merge.

@AshokDaparthi
Copy link
Contributor

@smaheshm - Can you merge this

@neethajohn neethajohn merged commit 459d3d1 into sonic-net:master Oct 19, 2021
dgsudharsan added a commit to dgsudharsan/sonic-buildimage that referenced this pull request Oct 29, 2021
dgsudharsan added a commit to dgsudharsan/sonic-buildimage that referenced this pull request Oct 29, 2021
ghooo added a commit to sonic-net/sonic-utilities that referenced this pull request May 25, 2022
#### 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)
yxieca pushed a commit to sonic-net/sonic-utilities that referenced this pull request Jun 17, 2022
#### 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)
yxieca pushed a commit to sonic-net/sonic-utilities that referenced this pull request Jun 23, 2022
#### 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)
malletvapid23 added a commit to malletvapid23/Sonic-Utility that referenced this pull request Aug 3, 2023
#### 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
YANG YANG model related changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants