Packet Drop Monitoring#2298
Conversation
Signed-off-by: JaiOCP <jai.kumar@broadcom.com>
| * | ||
| * @objects SAI_OBJECT_TYPE_TAM_EVENT_LEARN_ENTRY | ||
| */ | ||
| sai_object_id_t le_id; |
There was a problem hiding this comment.
does it make sense to make this object first in the structure?
There was a problem hiding this comment.
The attributes need a reference to the object hence I have kept it here in structure.
Any other suggestions?
There was a problem hiding this comment.
im just saying make it first field
There was a problem hiding this comment.
Just for curiosity. How does it help.
Alignment ??
There was a problem hiding this comment.
it does not change alignement, just from order perspective it make sense to have object id first and then it;s attributes, for example the same idea is when you create object or call set api, object id is first
| SAI_SWITCH_ATTR_OUT_DROP_REASON_LIST, | ||
|
|
||
| /** | ||
| * @brief List of supported buffer drop reasons |
There was a problem hiding this comment.
In both Ingress and Egress, there are two kinds of drops: drops before packet processing and drops after packet processing. For example, most architectures have an early drop mechanism to handle oversubscription. Based only on packet header attributes (such as the dscp or ieee priority bits), low priority packets are dropped before even entering the pipeline. This is done to conserve pipeline resources and allow control packets through even during heavy, ASIC-wide congestion such as oversubscription. However, since the packets have not been processed, the drop decision is rather crude and without any exceptions. Ideally, you want to drop packets after packet processing, which could remark the priority of the packet or a set a pipeline attribute such as "drop precedence". Most architectures have a set of virtual statistics queues (VSQs) for this purpose where buffer limits can be set based on priority, class, filter results, etc. Note: the drop decision may be probabilistic such as WRED, but fundamentally it is the same mechanism. Both kinds of drops, pre and post packet processing, could be considered "buffer drops" or "mmu drops" since they're based on buffer thresholds. Therefore, it might be useful to separate Ingress admission drops from Ingress processing drops. In addition, there are also rare, hardware related buffer drops such as corrupted dram reads.
The situation at Egress is similar. In a fabric architecture, packets could be dropped before they are even assembled, e.g. cells dropped due to CRC errors. Also, packets could be dropped before entering the pipeline based on various thresholds, such as the global buffer limits for unicast/multicast, the drop precedence carried from Ingress, packet buffer and descriptor limits per QoS, multicast replication resource limits, etc. Once in the Egress pipeline, packets may be dropped because the destination queue is full or an Egress filter has decided to drop the packet. And again, there also are esoteric hardware specific reasons.
In summary, it would be useful to separate Ingress/Egress admission (pre pipeline) drops from post-processing drops.
| SAI_BUFFER_DROP_REASON_ANY = SAI_BUFFER_DROP_REASON_START, | ||
|
|
||
| /** IPG packet drops */ | ||
| SAI_BUFFER_DROP_REASON_IPG, |
There was a problem hiding this comment.
Create two sections using comments for "BUFFER_IN_DROP"
Ingress Priority Group Buffer
Queue Buffer Drops
3 participants
This PR introduces packet drop monitoring where monitoring can be enabled for a specific set of drop reasons for a specific stage of pipeline like ingress, egress and buffer. If this is done with hw learning enabled for deduplcation then this form packet drop monitoring is considered stateful.
This PR introduces framework for both stateful and stateless packet drop monitoring.
Accidentally closed PR
#2290