TRIM to Sender and TC-DSCP Map

[JaiOCP]

This PR address the usecase of setting different DSCP for TRIM packets going out on different port as mentioned in
https://github.com/JaiOCP/SAI/blob/master/doc/SAI-Proposal-Packet-Trimming.md

Current usage of SAI_PORT_ATTR_QOS_TC_AND_COLOR_TO_DSCP_MAP creates an issue where when TRIM TC is enabled for DSCP marking any other traffic flowing out on the port need to be correctly marked for TC to DSCP even if there is no change in outgoing DSCP. This is because once a map is enabled for a port, SAI spec mandates a default behavior of mapping to TC 0. This is not acceptable if there is requirement to map TC to DSCP only for TRIM packets.

New attribute SAI_PORT_ATTR_QOS_TRIM_TC_AND_COLOR_TO_DSCP_MAP is introduced to control only TRIM related TC to DSCP map and not touch the other data traffic maps.

New attribute SAI_BUFFER_PROFILE_PACKET_ADMISSION_FAIL_ACTION_DROP_AND_TRIM_TO_SENDER is introduced where TRIM packets can be forwarded in the reverse direction to the sender. All the other attributes for TRIM as applicable including stats remains same.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[tjchadaga]

• @vmittal-msft, @kperumalbfn

[eddyk-nvidia]

@JaiOCP - please put the explanation from this PR into https://github.com/JaiOCP/SAI/blob/master/doc/SAI-Proposal-Packet-Trimming.md document

[rck-innovium]

@JaiOCP
On which port do the below stats increment for Trim-to-Sender packets? the port towards the receiver or the port towards the sender?

/** Packets trimmed but dropped due to failed shared buffer admission on a trim queue */
SAI_PORT_STAT_DROPPED_TRIM_PACKETS,

/** Packets trimmed and successfully transmitted on port */
SAI_PORT_STAT_TX_TRIM_PACKETS,

[JaiOCP]

@JaiOCP - please put the explanation from this PR into https://github.com/JaiOCP/SAI/blob/master/doc/SAI-Proposal-Packet-Trimming.md document

Updated the spec

[JaiOCP]

@JaiOCP On which port do the below stats increment for Trim-to-Sender packets? the port towards the receiver or the port towards the sender?

/** Packets trimmed but dropped due to failed shared buffer admission on a trim queue */
SAI_PORT_STAT_DROPPED_TRIM_PACKETS,

/** Packets trimmed and successfully transmitted on port */
SAI_PORT_STAT_TX_TRIM_PACKETS,

I went over the details of this stats again and here is my interpretation.
SAI_PORT_STAT_TRIM_PACKETS: These are TRIM packets because of the congestion on trim eligible queue and has nothing to do with direction these packets are send. Many queues may experience congestion and may be trim eligible. All these trim packets across queues are accounted under this stat.

SAI_PORT_STAT_DROPPED_TRIM_PACKETS: The are dropped TRIM packets because the queue on which they were supposed to go out got congested. Again I would say that there is nothing specific about direction here.

SAI_PORT_STAT_TX_TRIM_PACKETS: This one the TRIM packets that were forwarded on the port and is an important metrics to know how of a port bandwidth is consumed by this traffic. If we look carefully if a TRIM is sent to receiver or sender we want to know the BW consumed on the port. I would suggest that these stats are also inclusive of TRIM in both the directions.

Let me know what you and others think about it.

[JaiOCP]

@rbudhia-upscaleai @rck-innovium Please take a look. Review comments are addressed

[kperumalbfn]

@JaiOCP If map attached to port doesn't have any mapping for non-trim TCs, then DSCP remarking for regular packets is bypassed. For default TC=0, if there is no entry in the map attached to egress port, then packet remarking should be bypassed. Could you please clarify this?