You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scenario:
When lossless traffic is sent via the DUT and Pause frames are sent on the egress, the egress goes into stormed mode.
Since PFCWD and Credit-WD is enabled, all the packets get dropped and no lossless packet is sent out of the egress.
In 2205, for duration of storm detection few packets would be sent out, after which packets are completely stopped out of egress.
The queue counter would show ONLY packets sent out under 'Counter/pkts' and rest of dropped packets would be displayed under 'Drop/pkts'. So if ingress sends A packets to egress and egress drops B packets, 'Counter/pkts' is A-B and 'Drop/pkts' is B packets.
However, in 2405, 'Counter/pkts' shows all the packets received on the interface and dropped packets are incremented under 'Drop/pkts'. So, if ingress sends A packets to egress and egress drops B packets, 'Counter/pkts' is A and 'Drop/pkts' is B packets.
Example of 2205:
admin@ixre-egl-board72:~$ sudo ip netns exec asic0 show queue counters --nonzero
Ethernet0 Last cached time was 2024-12-03 20:09:17.303866
Port TxQ Counter/pkts Counter/bytes Drop/pkts Drop/bytes
--------- ----- -------------- --------------- ----------- ---------------
Ethernet0 UC3 126,497 127,508,976 421,358,651 424,729,520,208
Ethernet0 UC4 890,415 897,538,320 421,532,480 424,904,739,840
Ethernet0 UC7 19 4,902 0 0
Send Pause Storm on the egress, storming the egress port.
Attempt to send lossless traffic via the egress port.
Check the queue stats.
Describe the results you received:
In 2205, the 'Counter/pkts' would ONLY show the packets which are Tx'ed out of the box.
In 2405, behavior has changed, and stats shows cumulative packets received from ingress.
Describe the results you expected:
Consistent behavior across 2205 and 2405. Queue stats should show ONLY the Tx'ed packets out of egress rather than showing cumulative counter.
This will affect 'Snappi' sonic-management testcases where PAUSE is received on egress and 'verify_egress_queue_frame_count' is being called to check the queue-counter in event of PAUSE being received.
We have raised Broadcom issue - CS00012381231 to track the same.
In SAI 11.2, SAI_QUEUE_STAT_PACKETS & SAI_QUEUE_STAT_BYTES returns GREEN packets/bytes + GREEN_DROP packets/bytes whereas in SAI 7.1, it returns only GREEN packets/bytes. Created a csp CS00012381231
Description
Scenario:
When lossless traffic is sent via the DUT and Pause frames are sent on the egress, the egress goes into stormed mode.
Since PFCWD and Credit-WD is enabled, all the packets get dropped and no lossless packet is sent out of the egress.
In 2205, for duration of storm detection few packets would be sent out, after which packets are completely stopped out of egress.
The queue counter would show ONLY packets sent out under 'Counter/pkts' and rest of dropped packets would be displayed under 'Drop/pkts'. So if ingress sends A packets to egress and egress drops B packets, 'Counter/pkts' is A-B and 'Drop/pkts' is B packets.
However, in 2405, 'Counter/pkts' shows all the packets received on the interface and dropped packets are incremented under 'Drop/pkts'. So, if ingress sends A packets to egress and egress drops B packets, 'Counter/pkts' is A and 'Drop/pkts' is B packets.
Example of 2205:
Example of 2405:
Steps to reproduce the issue:
Describe the results you received:
In 2205, the 'Counter/pkts' would ONLY show the packets which are Tx'ed out of the box.
In 2405, behavior has changed, and stats shows cumulative packets received from ingress.
Describe the results you expected:
Consistent behavior across 2205 and 2405. Queue stats should show ONLY the Tx'ed packets out of egress rather than showing cumulative counter.
This will affect 'Snappi' sonic-management testcases where PAUSE is received on egress and 'verify_egress_queue_frame_count' is being called to check the queue-counter in event of PAUSE being received.
We have raised Broadcom issue - CS00012381231 to track the same.
Tagging @saksarav-nokia
Output of
show version
:Output of
show techsupport
:Additional information you deem important (e.g. issue happens only occasionally):
The text was updated successfully, but these errors were encountered: