Closed rraghav-cisco closed 1 year ago
@neethajohn : Pls give your opinion.
@XuChen-MSFT can you assess this requirement?
@rraghav-cisco , maybe better way is that each vendoer can dynamically generate specific qos paramer. for example:
qpm = qos_param_generator.QosParamMellanox(qosConfigs['qos_params']['mellanox'][dutTopo], dutAsic,
portSpeedCableLength,
dutConfig,
ingressLosslessProfile,
ingressLossyProfile,
egressLosslessProfile,
egressLossyProfile,
sharedHeadroomPoolSize,
dutConfig["dualTor"]
)
qosParams = qpm.run()
in above existing platform dependency implementation, vendor's script take partial of qos.yml which is related to vendor platform, and other factor such as dutconfig, various profile, port speed and cable lenght, etc. and then calculate qos test parameter in runtime. finally update calculation result to the qos.yam daynamically to feed to qos testcase.
in this way, existing qos.yml is just reference template for script generating correct qos test parameters. we don't need to maintain it anymore. It can also overcome a shortage of qos.yam, that is, the qos.yam file only contain the static test parameter. It cannot well support changes in the test env/config, such as changes of topology, PG, and queue.
@XuChen-MSFT Absolutely. That is what I wanted in the first place. Who can do it?
@rraghav-cisco Every vendor needs to implement themself own script to generate QoS test parameters for their platform.
You can reference below existing implementation and invoking: https://github.com/sonic-net/sonic-mgmt/blob/67e7688bda24814829fce1eee0efef27f12113a9/tests/qos/qos_sai_base.py#L999
resolve in PR 8860
Hi,
The file: tests/qos/files/qos.yml has become very big, and has a lot of fields that have to be populated per platform. Can we pls split it based on platform or asic or even vendor ? That will help in managing it better.
Thanks, rraghav