Skip to content

Conversation

@ccroy-arista
Copy link
Contributor

Description of PR

The current calculation method for the RX PPS rate for the COPP tests is not very accurate (in some cases 130-150% above nominal) due to the reliance of sampling received packets at the ptf container on the testbed server after sending the packet stream, while also using a timeout to wait for said packets to finish arriving. This does not capture the in-flight RX PPS rate, but rather takes an average outside of the actual packet transmission window, and incurs additional inaccuracies due to the wait time at the end.

A more accurate approach implemented here is to take two snapshots of the RX packet count at the NN agent on the dut itself while the packet stream is already running, and calculate the difference.

Summary:
Fixes # (issue)

Type of change

  • Bug fix
  • Testbed and Framework(new/improvement)
  • New Test case
    • Skipped for non-supported platforms
  • Test case improvement

Back port request

  • 202205
  • 202305
  • 202311
  • 202405
  • 202411
  • 202412
  • 202511

Approach

What is the motivation for this PR?

To fix neighbor_miss tests failing for TH5 duts on 202412, and enhance the COPP tests overall for more accurate results.

How did you do it?

Updated the calculation method used to get the RX PPS rate for the COPP tests.

How did you verify/test it?

Ran the copp tests and verified that the resulting RX PPS values were within range.

The current calculation method for the RX PPS rate
for the COPP tests is not very accurate (in some
cases 130-150% above nominal) due to the reliance
of sampling received packets at the ptf container
on the testbed server after sending the packet
stream, while also using a timeout to wait for
said packets to finish arriving. This does not
capture the in-flight RX PPS rate, but rather
takes an average outside of the actual packet
transmission window, and incurs additional
inaccuracies due to the wait time at the end.

A more accurate approach implemented here is to
take two snapshots of the RX packet count at the
NN agent on the dut itself while the packet stream
is already running.

Signed-off-by: Christopher Croy <[email protected]>
The COPP test for the ARP packet type does not
account for the fact that there are two ARP
trap IDs being acted upon in the target COPP trap
group: arp request and arp response.

Set the dst_ip to a non-reachable IP to avoid
generating an ARP response which would, depending
on the underlying trap rate calculation being
used, erroneously yield double the nominal rate.

Signed-off-by: Christopher Croy <[email protected]>
@mssonicbld
Copy link
Collaborator

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ccroy-arista
Copy link
Contributor Author

Supersedes #21629

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants