- Why I did it Configure different DSCP_TO_TC_MAP between uplink and downlink on T1 switch in dual ToR scenario On T1 uplink, both DSCP 2/6 will be mapped to TC 1 for the purpose of avoiding such traffic occupying lossless buffers. On T1 downlink, they will be mapped to TC 2/6 respectively. (unchanged) - How I did it For vendors who want to configure different DSCP_TO_TC_MAP between uplinks and downlinks on T1, they should Define generate_dscp_to_tc_map macro in SKU's qos.json.j2 file Define map AZURE for downlink and AZURE_UPLINK for uplink Define jinja2 variable different_dscp_to_tc_map as True Signed-off-by: Stephen Sun <stephens@nvidia.com> |
||
---|---|---|
.. | ||
per_namespace | ||
share_image | ||
arp_update_vars.j2 | ||
buffers_config.j2 | ||
config-chassisdb.service.j2 | ||
config-setup.service.j2 | ||
database.service.j2 | ||
dhcp_relay.service.j2 | ||
docker_image_ctl.j2 | ||
gbsyncd.service.j2 | ||
iccpd.service.j2 | ||
init_cfg.json.j2 | ||
kube_cni.10-flannel.conflist | ||
lldp.service.j2 | ||
lldp.timer.j2 | ||
mgmt-framework.service.j2 | ||
mgmt-framework.timer | ||
mux.service.j2 | ||
nat.service.j2 | ||
organization_extensions.sh | ||
pmon.service.j2 | ||
pmon.timer | ||
qos_config.j2 | ||
radv.service.j2 | ||
restapi.service.j2 | ||
sflow.service.j2 | ||
snmp.service.j2 | ||
snmp.timer | ||
sonic_debian_extension.j2 | ||
sonic-delayed.target | ||
sonic.target | ||
swss_vars.j2 | ||
tacacs-config.service | ||
tacacs-config.timer | ||
telemetry.service.j2 | ||
telemetry.timer | ||
updategraph.service.j2 |