sonic-buildimage
sonic-buildimage copied to clipboard
[Broadcom-DNX][Nokia] ECN marking is not happening at configured Kmin and Kmax value.
Description
This issue is reported in response to the ECN test-cases present in snappi_tests/multidut/ecn folder.
Steps to reproduce the issue:
- Configured Kmin and Kmax value to 800k and 1200k bytes.
- Set Pmax to 100.
- Configure alpha threshold to 3 (2^3) [This step is optional and does not alter testcase functionality].
- Send pause on the egress port.
- Send 5k packets with 1024B.
Describe the results you received:
- All packets from 267 to around 4996 are ECN-marked.
- This does not change even if the Kmin and Kmax thresholds are changed.
Describe the results you expected:
We have a Broadcom CSP open to understand the queuing/de-queuing aspects involved in ECN marking.
Output of show version:
(paste your output here)
Output of show techsupport:
(paste your output here or download and attach the file here )
Additional information you deem important (e.g. issue happens only occasionally):
Tagging @saksarav-nokia
Following with BCM with CS00012362297
BCM's comments:
When unicast packets are received on a NIF port they are then sent to a VOQ based on processing in the ingress pipeline (IRPP). In congestion scenarios these packets are then sent to DRAM when thresholds are crossed.
Also, the packets are marked with ECN on dequeue. This is why you are seeing the packets marked before the min threshold when the queue is heavily congested.
The CNI status is tagged per DRAM bundle instead of per packet when the packets are sent from SRAM to DRAM. This is why you were also seeing most of the last packets being marked when they were going to DRAM. This is not the case when all of the packets go to OCB.
The ECN test with XGS or other pizza boxes where we count ECN marked packets is going to be very difficult with DNX with different thresholds (because of the drop probabilities and DRAM bundling).
A simpler approach might be to have a test with the kmin setting where you see no marking and then another test in between kmin and kmax where you want to confirm that packets are being marked.
@saksarav-nokia is this still an issue?
We had debug session with Broadcom pertaining to this.
Existing Snappi-IXIA test case
This testcase sets the Kmin and Kmax to 50 and 51 packets respectively, and hence only single packet difference.
Following was the synopsis of the meeting with Broadcom:
- The Kmin and Kmax values are too close and require bigger range of Kmin and Kmax.
- For Broadcom-DNX platforms, ingress offers credits to the egress during congestion. Hence initial few packets are sent to the egress with NO ECN-marking. This is around 250-270 packets for 100Gbps interfaces and around 750-770 packets for 400Gbps interfaces.
- On Broadcom DNX platforms, once the number of packets cross the Kmax values, the packets are moved to DRAM, where all the packets are ECN marked, thus not following Pmax marking probability.
The above testcase needs to be modified for the Broadcom-DNX platform. There is already an existing PR for the same.
Hence closing this issue.
Thanks,