testpmd: simulating noisy host environment

This RFC patch propose enhancements to testpmd to simulate more realistic behavior of a guest machine engaged in receiving and sending packets performing Virtual Network Function (VNF).

The goal is to enable simple of measuring performance impact on cache and memory footprint utilization from various VNF co-located on the same host machine.

This series of patches adds the new command line switches to testpmd:

--buffersize-before-sending [packet numbers]

Keep the mbuf in a FIFO and forward the over flooding packets from the FIFO. This queue is per TX-queue (after all other packet processing).

--flush-timer [delay]
Flush the packet queue if no packets have been seen during [delay]. As long as packets are seen, the timer is reset.

Options to simulate route lookups:

--memory-footprint [size]
Size of the VNF internal memory (MB), in which the random read/write will be done, allocated by rte_malloc (hugepages).

--random-w-memory-access-per-packet [num]
Number of random writes in memory per packet should be performed, simulating hit-flags update. 64 bits per write, all write in different cache lines.

--random-r-memory-access-per-packet [num]
Number of random reads in memory per packet should be performed, simulating FIB/table lookups. 64 bits per read, all write in different cache lines.

--random-rw-memory-access-per-packet [num]
Number of random reads and writes in memory per packet should be performed, simulating stats update. 64 bits per read-write, all reads and writes in different cache lines.

Options to simulate packet processing (encap/decap)

--read-packet-buf [0-100]
Determine the percentage of cache lines of a packet mbuf that testpmd should read for every packet.

--write-packet-buf [0-100]
Determines the percentage of cache lines in the packet mbuf testpmd should write to.

Comments are welcomed. If name of command line switches seems reasonable, I'll send rest of the patches with the implementation in few days.

Regards,

Victor

Hi,

while I think this functionality is of use, I don't think it should go into testpmd. Testpmd is designed for testing NIC PMDs, and not as a general test tool, and is already complicated enough with lots of commandline options. For the task of testing VNF use-cases, I think a new separate app or example would be better.

My 2c.

/Bruce

31/10/2017 11:13, Bruce Richardson:

Not sure.
If we need to mix the VNF simulation options with the NIC features options (implemented in testpmd), then testpmd would be a good fit.

Please Victor, give your arguments to make the discussion progressing.

Hi,

o testpmd is already the primary tool used by both DPDK developers, testers
and for performance evaluations. Performances reports are available on dpdk.org for each DPDK releases, on various NICs, so it is a common baseline.

o testpmd is being used not only for NIC testing, but as a switch replacement
on the host, by OPNFV VSPerf and FD.io CSIT

o A single tool to cover all testing scenarios makes a lot of sense. It
will make testpmd even more popular on communities using DPDK and surely promote DPDK.

I fully understand the desire to keep testpmd as simple as possible, and we can address this by making the additional functionality as modular as possible in the source code. Or, if you prefer, we can create another tool even more basic then current testpmd just as an example for educational purposes.

What do you say?

----- Original Message -----