Dell - Internal Use - Confidential Hi, Please find the replies inline.
Thanks Anbalagan From: opencompute-networking-boun...@lists.opencompute.org<mailto:opencompute-networking-boun...@lists.opencompute.org> [mailto:opencompute-networking-boun...@lists.opencompute.org] On Behalf Of Itai Baz Sent: Saturday, September 26, 2015 6:09 AM To: opencompute-networking@lists.opencompute.org<mailto:opencompute-networking@lists.opencompute.org> Subject: Re: [Opencompute-networking] Few questions / comments re Qos maps spec Hi, In internal spec review we did for Qos maps spec, we came up with the following points : 1) For Ingress traffic, we have SAI_QOS_MAP_DOT1P_TO_TC and SAI_QOS_MAP_DOT1P_TO_COLOR Why is SAI_QOS_MAP_DOT1P_TO_TC_AND_COLOR needed, as seems redundant and coarse compared to using the first 2 ? Same for SAI_QOS_MAP_DSCP_TO_TC, SAI_QOS_MAP_DSCP_TO_COLOR, SAI_QOS_MAP_DSCP_TO_TC_AND_COLOR <DELL> The mapping between DOT1P to TC and DOT1P to COLOR can be present in the same hardware table or they can be in separate tables. In case they are in same table the map type SAI_QOS_MAP_DOT1P_TO_TC_AND_COLOR can be used. In case the mappings are in separate tables the DOT1P_TO_TC and DOT1P_TO_COLOR maps can be used. The support would depend on how the NPU handles the mapping in hardware. The problem with using separate DOT1P to TC and DOT1P to COLOR map in case of a combined hardware table is that it would lead to maintaining bookkeeping information in SAI which we feel is unnecessary overhead. The same applies to ingress DSCP maps also. If everyone agrees then we can have a single map which provides both the mappings. The map structure definition in saitypes.h is such that it can map any number of keys to any number of values. SAI_QOS_MAP_DOT1P_TO_TC_AND_COLOR SAI_QOS_MAP_DSCP_TO_TC_AND_COLOR alone can be used. 2) For egress traffic, we have SAI_QOS_MAP_TC_AND_COLOR_TO_DSCP Why is SAI_QOS_MAP_TC_TO_DSCP needed ? Seems redundant, as coarse compared to the first attribute, and everything done by the 2nd can be done with the first attribute Same for SAI_QOS_MAP_TC_AND_COLOR_TO_DOT1P, SAI_QOS_MAP_TC_TO_DOT1P <DELL> Similar to the ingress Dot1p and Dscp maps the index to the egress maps can be either TC or Color or Tc and Color. This again is NPU dependent and so we added the separate TC to DSCP/DOT1P or Color to DSCP/DOT1P or TC_AND_COLOR to DOT1P/DSCP. We can have the combination SAI_QOS_MAP_TC_AND_COLOR_TO_DSCP/DOT1P if everyone agree. 3) Re SAI_QOS_MAP_PRIORITY_GROUP_TO_PFC_PRIORITY SAI_QOS_MAP_PFC_PRIORITY_TO_QUEUE We think the mapping should be opposite way around, meaning it should be: SAI_QOS_MAP_PFC_PRIORITY_TO_PRIORITY_GROUP SAI_QOS_MAP_QUEUE_TO_PFC_PRIORITY As several PFC priorities can be mapped to same group <DELL> SAI_QOS_MAP_PRIORITY_GROUP_TO_PFC_PRIORITY – This map type is for generating the pause frames on the particular priority in the PG when the PG becomes congested. SAI_QOS_MAP_PFC_PRIORITY_TO_QUEUE - This map type is for honoring the pause frames. When pause is received on a particular priority then the sender should stop transmitting out on the queue mapped by the priority. This is as per our understanding. 4) We think a new SAI_PORT_ATTR_UPDATE_DOT1P attribute is needed in order to enable DOT1P updating on the ingress port like the existing one for the DSCP - SAI_PORT_ATTR_UPDATE_DSCP. <DELL> Yes it can be added. But we are not sure whether it is ingress setting or egress remarking. We need to define separate attributes for ingress and egress. 5) Does the DOT1P mappings include only the 3 PCP bits, or also the DEI/CFI bit ? <DELL> The CFI/DEI bits are not used for now. A new mapping can be defined in case its needed. 6) Re usage of SAI_PORT_ATTR_QOS_*_MAP and SAI_SWITCH_ATTR_QOS_*_MAP What is the expected behavior ? If you set several ports and then set the switch attribute, will the switch attribute affect only the ports that are at default state and weren’t explicitly set ? Would like to avoid this bookkeeping, similar to our decision on default pvid a month ago Suggest that the application either uses the port attributes, or the switch attributes, but not both. Or at least need to define clear semantics. <DELL> The port level maps will take precedence over the switch level maps. For ports in default state switch level maps would apply. If the map type is removed from a port then the corresponding switch level map if present would take effect. Having separate port level and switch level maps gives added flexibility. In case NPU supports only lesser number of profiles per map type a switch level map can be used. In case of NPUs which can support a profile per port the port level map can be used. Also some NPUs do not have the capability to support per port level maps. The switch level maps can be used in such cases. Appreciate your feedback Thanks, Itai
_______________________________________________ opencompute-networking mailing list Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking opencompute-networking@lists.opencompute.org http://lists.opencompute.org/mailman/listinfo/opencompute-networking
