-
Notifications
You must be signed in to change notification settings - Fork 148
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
Update qos_output_queue_counters_test.go #1131
Conversation
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.
Can you explain why rename queue names?
Please also mention that why vendor specific workarounds are needed? Is there any bug to track the workaround?
At least part of the problem really stems from a deficiency in the OC-QoS model. Silicon One ASIC's have a concept called a 'traffic-class' which also exists in many other asics. This traffic-class is a numeric identifier. In IOS XR's configuration model, this traffic class has a tight coupling to a specific priority value in the case of strict priority schedulers. The missing traffic-class equivalent has been a long-standing concern for this model, however it now appears to be getting addressed through the introduction of queue-identifiers in pull 772 for OC-QoS. The way that this missing functionality is addressed seems to be varying across implementors. In XR we are allocating the traffic-class in the order they appear in config to satisfy the ordering requirements of the scheduling model. In order to get this to show up properly via OC, we are using queue names that are defined lexically ordered according to the desired scheduling policy. Alternatives that implementors may use could include fixed queue names with an out of band association, or magic fixed queue names. Each approach has downsides. We expect this ordering issue to be addressed after the merge of PR772. Separately, QoS scheduling models are likely to vary across hardware platforms, and should be expected to change according to the asic/os implementation even when OC is used. |
Operationally I'd like to keep the queue names the same. But we can use CLI
commands to map the traffic class identifiers to the open config queue
names.
The OC model solution for this specific scenario will be merged soon.
…On Thu, Feb 16, 2023, 8:07 AM Aaron Millisor ***@***.***> wrote:
Can you explain why rename queue names?
Please also mention that why vendor specific workarounds are needed? Is
there any bug to track the workaround?
At least part of the problem really stems from a deficiency in the OC-QoS
model. Silicon One ASIC's, similar to many others in the industry, have a
concept called a 'traffic-class' which also exists in many other asics.
This traffic-class is a numeric identifier.
In IOS XR's configuration model, this traffic class has a tight coupling
to a specific priority value in the case of strict priority schedulers
<https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/qos/70x/configuration/guide/b-qos-cg-8k-70x/traffic_management_overview.html#concept_izx_bhw_m3b>
.
The missing traffic-class equivalent has been a long-standing concern for
this model, however it now appears to be getting addressed through the
introduction of queue-identifiers in pull 772 for OC-QoS
<openconfig/public#772>.
The way that this missing functionality is addressed seems to be varying
across implementors. In XR we are allocating the traffic-class in the order
they appear in config to satisfy the ordering requirements of the
scheduling model. In order to get this to show up properly via OC, we are
using queue names that are defined lexically ordered according to the
desired scheduling policy.
Alternatives that implementors may use could include fixed queue names
with an out of band association, or magic fixed queue names. Each approach
has downsides.
We expect this ordering issue to be addressed after the merge of PR772.
Separately, QoS scheduling models are likely to vary across hardware
platforms, and should be expected to change according to the asic/os
implementation even when OC is used.
—
Reply to this email directly, view it on GitHub
<#1131 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMCGM7TUFSPGC22BGDORDDWXZGEHANCNFSM6AAAAAAU5JJMMU>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
Pull Request Test Coverage Report for Build 4318098964
💛 - Coveralls |
Internal test result: b/269634520 |
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.
/gcbrun
.../experimental/qos/ate_tests/qos_output_queue_counters_test/qos_output_queue_counters_test.go
Outdated
Show resolved
Hide resolved
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.
Per the discussion with aaronmillisor yesterday, please add the bug# for the workaround.
Please also address the comment about DSCP change as well.
/gcbrun |
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.
Does the test pass in your test bed with this PR?
Internal test result: b/269634520 |
We (Sean, Viktor, Cisco team and I) had a discussion (b/268403096#comment9). Viktor has filed bugs to track the explanation of Cisco implementation, and we decided to move forward with this PR. |
Sean, Viktor, Cisco team and Craig had a discussion (b/268403096#comment9). Viktor has filed bugs to track the explanation of Cisco implementation, and we decided to move forward with this PR.
* Replicate PR1018 in OTG QoS output queue counters test Reference: #1018 * Replicate PR1100 in OTG QoS output queue counters test Reference: #1100 * Replicate PR1089 in OTG QoS output queue counters test Reference: #1089 * Replicate PR1090/1087 in OTG QoS output queue counters test References: - #1090 - #1087 * Replicate PR1167 in OTG QoS output queue counters test Reference: #1167 * Replicate PR1177 in OTG QoS output queue counters test Reference: #1177 * Replicate PR1131 in OTG QoS output queue counters test Reference: #1131 * Replicate PR1219 in OTG QoS output queue counters test Reference: #1219 * Replicate PR1221 in OTG QoS output queue counters test Reference: #1221 * Replicate PR1234 in OTG QoS output queue counters test Reference: #1234 * Replicate PR1276 in OTG QoS output queue counters test Reference: #1276 * Replicate PR1395 in OTG QoS output queue counters test Reference: #1395
* Update qos_output_queue_counters_test.go * Update qos_output_queue_counters_test.go * Update qos_output_queue_counters_test.go --------- Co-authored-by: vbhan-cisco <92700680+vbhan-cisco@users.noreply.github.com> Co-authored-by: prinikasn <117314826+prinikasn@users.noreply.github.com>
* Replicate PR1018 in OTG QoS output queue counters test Reference: #1018 * Replicate PR1100 in OTG QoS output queue counters test Reference: #1100 * Replicate PR1089 in OTG QoS output queue counters test Reference: #1089 * Replicate PR1090/1087 in OTG QoS output queue counters test References: - #1090 - #1087 * Replicate PR1167 in OTG QoS output queue counters test Reference: #1167 * Replicate PR1177 in OTG QoS output queue counters test Reference: #1177 * Replicate PR1131 in OTG QoS output queue counters test Reference: #1131 * Replicate PR1219 in OTG QoS output queue counters test Reference: #1219 * Replicate PR1221 in OTG QoS output queue counters test Reference: #1221 * Replicate PR1234 in OTG QoS output queue counters test Reference: #1234 * Replicate PR1276 in OTG QoS output queue counters test Reference: #1276 * Replicate PR1395 in OTG QoS output queue counters test Reference: #1395
No description provided.