Honeycomb performance test proposal

Samuel Elias -X (samelias - PANTHEON TECHNOLOGIES@Cisco)


My Initial proposal for Honeycomb performance testing is as follows.


- single Jenkins job, manually triggered. Change to weekly once it's showing good numbers.

- use VPP and Honeycomb packages from Nexus, and ODL client(Boron-SR3).

Note: ODL may have to be stored locally due to the download size(around 400MB) - on the test nodes? on Nexus?

test setup:

- setup VPP+Honeycomb+ODL stack on DUT1

- setup TRex on TG

- use TRex to generate Restconf requests

- send requests to ODL, performing CRUD operations on VPP config

- catch and measure responses on TG

Note: Management requests cannot be sent over the data plane(VPP interfaces), as they need to be received by ODL's listener. Assuming the management interfaces(10.30.51._ range) should not be used for tests, we will have to give control of VPP's "tg_to_dut1" test interface back to the linux OS for the duration of test.

test cases:

(initially using L2-FIB yang model, it's simple and scaleable)

Given X amount of configured FIB entries

- TC01: avg. delay of read operation

- TC02: avg. delay of write operation

- TC03: max rate of read operations

- TC04: max rate of write operations

using NDR binary search to determine max rate.

Expected execution time for the initial cases (incl. suite setup and teardown): <60min

Thoughts and opinions are welcome.


- Sam