Performance Data - raw first cut

[gshanemiller]

I've started this work.

The library does not have congestion control, nor does it detect dropped packets in the RX/TX main loop. So in the first cut of this report will:

• configure X TXQs on box1 (up to 32 are possible)
• configure Y RXQs on box2 (up to 32 are possible)
• TX N packets per queue
• Report aggregate pps, bytes/sec
• Report packets dropped

I almost have this code now. The problem is understanding the stats. For example in the current work I see this for the TX side. Here the config is 2 TXQs sending 100005 packets each. The code appears to run, and shut down without any errors. But note:

lcoreId: 0, txqIndex: 0, packetsQueued: 100005, sleeps: 0, totalSleepTimeNs: 0
lcoreId: 1, txqIndex: 1, packetsQueued: 100005, sleeps: 0, totalSleepTimeNs: 0
in  packets : 0
out packets : 199136                              <---- this number is not 100005 x 2
in  bytes   : 0
out bytes   : 10753344
missed pkts : 0
in err pkts : 0
out err pkts: 0
rx allc errs: 0
txq: 0, in  packets : 0
txq: 0, out packets : 100005                  <---- this number seems to claim it really wrote all 100005 pkts on the wire
txq: 0, in bytes    : 0
txq: 0, out bytes   : 5400270
txq: 0, missed pkts : 0
txq: 1, in  packets : 0
txq: 1, out packets : 100005                  <---- ditto
txq: 1, in bytes    : 0
txq: 1, out bytes   : 5400270
txq: 1, missed pkts : 0
tx_good_packets: 199200
tx_good_bytes: 10756800
tx_q0_packets: 100005
tx_q0_bytes: 5400270
tx_q1_packets: 100005
tx_q1_bytes: 5400270
dev_start: 1
tx_q0_cnt: 100005
tx_q1_cnt: 100005
tx_q0_bytes: 5400270
tx_q1_bytes: 5400270
tx_q0_tx_poll: 4547174
tx_q1_tx_poll: 4594861
tx_q0_doorbells: 18812
tx_q1_doorbells: 18861
tx_q0_available_desc: 6
tx_q1_available_desc: 10

On the RXQ side about 8% of the packets never appear delivered. Like the TX side, the total number of IN packets is not 2 * 100005 either. So the question is what per queue stats differ from aggregate stats on data from the DPDK API.

Working out what this noise is.

[gshanemiller]

amzn/amzn-drivers#166

is related. For now the UDP demo (sigh) just sleeps before the lcores exit to allow the HW to finish

[gshanemiller]

Closing - see benchmarks in README.md top level. So far it's bad.