RFC2544 behaviour anomalies

[jlixfeld]

I just ran my first rfc2544 test and want to report a few things I saw that I think aren't intended:

./MoonGen ../rfc2544/master.lua --txport 1 --rxport 4

My topology is one 6 port 82599EB SFP+ NIC with ports 1 and 4 looped together running on a Debian 8.4 machine.

-[0000:00]-+-00.0 Intel Corporation Haswell-E DMI2 +-01.0-[01]-- +-02.0-[02-07]----00.0-[03-07]--+-04.0-[04]--+-00.0 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | | -00.1 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | +-05.0-[05]--+-00.0 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | | -00.1 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | +-08.0-[06]-- | -09.0-[07]--+-00.0 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | -00.1 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection

1. Is there a way to automate it so one doesn't need to keep agreeing to add and remove the IP from the tx and rx interface? I was asked 83 times through the duration of one test.

configure: add to interface nil ip 198.18.1.1/24continue (y/n)? y configure: add to interface nil ip 198.19.1.1/24continue (y/n)? y configure: delete from interface nil ip 198.19.1.1/24continue (y/n)? y configure: delete from interface nil ip 198.18.1.1/24continue (y/n)? y

1. Is there a way to quite the output down and not report the fact that it is unable to load the modules it isn't able to load? The test printed these unable to load module warnings over 1000 times during a run.

unable to load snmp module unable to load mikrotik ssh module unable to load freeBSD ssh module unable to load linux ssh module

1. At various points throughout the run, I kept getting PMD warnings about queues. Are these anything to worry about?

PMD: ixgbe_dev_tx_queue_stop(): Could not disable Tx Queue 1 PMD: ixgbe_dev_tx_queue_stop(): Could not disable Tx Queue 2 PMD: ixgbe_dev_tx_queue_stop(): Could not disable Tx Queue 3 PMD: ixgbe_dev_tx_queue_stop(): Tx Queue 1 is not empty when stopping. PMD: ixgbe_dev_tx_queue_stop(): Tx Queue 2 is not empty when stopping. PMD: ixgbe_dev_tx_queue_stop(): Tx Queue 3 is not empty when stopping.

1. My first run between two ports on the same card resulted in a segmentation fault:

... ... ... Memory allocation failed: Cannot allocate memory (12) Memory allocation failed: Cannot allocate memory (12) Segmentation fault root@pgen:~/MoonGen/build#

My install is nothing more involved than what the installation document described. IE: No 3rd party versions of dpdk or anything like that.

Thanks in advance!

[emmericp]

1) this is automated by the various config modules but that doesn't work since you are just using a cable as device under test

2) no

3) this is a bug in DPDK since DPDK 2.0, will hopefully be fixed sometimes

4) related to 3), the bug leaks some memory. allocate more memory (via hugetlbfs) as a work-around

[jlixfeld]

Hi Paul,

1. I don't follow. What are you referring to by config modules? Are you saying that it's a user error and if I configure it a better way, it will behave in a more autonomous manner instead of wanting me to do stuff with IP information after each test and sub test?
2. I've been trying to convert the .tikz results to .pdf but I'm getting some errors. Do you have any pointers as to why I might be having issues pdf'ifying these? I'm using a python script that I found which claims to be able to do the job, but what do I know :)

https://github.com/oso/tikz2pdf

...

! LaTeX Error: Can be used only in preamble.

See the LaTeX manual or LaTeX Companion for explanation. Type H for immediate help. ...

l.1 \documentclass {standalone} 531 words of node memory still in use: 12 hlist, 1 vlist, 2 rule, 1 kern, 41 glue_spec, 1 write, 1 dir, 16 pdf_liter al, 8 pdf_refxform, 17 pdf_colorstack nodes avail lists: 2:29,3:1,4:2,6:2 ! ==> Fatal error occurred, no output PDF file produced! Transcript written on tikz2pdf_TSN_Z5.log.

ERROR generating /home/jlixfeld/testresults_2016-05-31_12-08/plot_throughput_mpps.tikz.pdf with pdflatex (rc = 1)

Thanks again for your input.

[emmericp]

1) yes, it's fully automated if your DuT is a supported system (snmp or linux/freebsd/mikrotik via SSH)

2) looks like that script is trying to prepend another preamble to our output. all our reports are already full latex documents, so you can just compile them with pdflatex or whatever you are using.

[benerudolph]

@jlixfeld If I remember correctly you need to install the “standalone“ latex documentclass package first. It is not part of the default TeX distributions afaik. I ran the rfc2544 scripts with success. However I see the point that there is a lack of documentation. Maybe a Readme.md file in the rfc2544 directory would help.

[jlixfeld]

Thanks @emmericp & @benerudolph using pdflatex worked fine. standalone is in fact installed, but for some reason that script I was running didn't think it was, or something.

Paul, could you help me understand what MoonGen would expect the DuT to do once rfc2544 was able to ssh to it (or successfully poll it via SNMP)? My experience with RFC2544 testing has been through the use of specialty devices, such as an Exfo which can be used in a bunch of different modes: single test-set mode with a single tester (where the same tester is the transmitter and the receiver), single test-set mode with two testers (where one tester is the transmitter and one tester is the receiver), and dual test-set mode with two testers (where both testers are both the transmitters and the receivers to test bi-directionally). In either case, the DuT is just some device that sits in the middle between the transmitter and receiver (or, in my case simply a cable connecting the tx port to the rx port :)). There isn't any use case that I am familiar with which requires the tester to connect to the DuT.

In any event, I tried to get MoonGen to ssh to itself, but it says it's unable to load the Linux ssh module:

root@pgen:~/MoonGen/build# ./MoonGen ../rfc2544/master.lua --txport 4 --rxport 1 --din 4 -dout 4 --asksshpass true --sshuser jlixfeld --host localhost --snmpcomm mycomm [INFO] Initializing DPDK. This will take a few seconds... [INFO] Found 7 usable devices: Device 0: 00:0C:BD:08:80:9C (82599EB 10-Gigabit SFI/SFP+ Network Connection) Device 1: 00:0C:BD:08:80:9D (82599EB 10-Gigabit SFI/SFP+ Network Connection) Device 2: 00:0C:BD:08:80:9A (82599EB 10-Gigabit SFI/SFP+ Network Connection) Device 3: 00:0C:BD:08:80:9B (82599EB 10-Gigabit SFI/SFP+ Network Connection) Device 4: 00:0C:BD:08:80:98 (82599EB 10-Gigabit SFI/SFP+ Network Connection) Device 5: 00:0C:BD:08:80:99 (82599EB 10-Gigabit SFI/SFP+ Network Connection) Device 6: 0C:C4:7A:AB:F9:C1 (I350 Gigabit Network Connection) [WARN] You are running Linux >= 3.14, DDIO might not be working with DPDK in this setup! [WARN] This can cause a huge performance impact (one memory access per packet!) preventing MoonGen from reaching line rate. [WARN] Try using an older kernel (we recommend 3.13) if you see a low performance or huge cache miss ratio. unable to load snmp module unable to load mikrotik ssh module unable to load freeBSD ssh module unable to load linux ssh module password: ** [INFO] Waiting for devices to come up... [INFO] Device 1 (00:0C:BD:08:80:9D) is up: full-duplex 10000 MBit/s [INFO] Device 4 (00:0C:BD:08:80:98) is up: full-duplex 10000 MBit/s [INFO] 2 devices are up. frame size(byte),duration(s),max loss rate(%),rate threshold(packets),rate(mpps) iter1,spkts(byte) iter1,rpkts(byte) iter1 configure: add to interface 4 ip 198.18.1.1/24continue (y/n)? y unable to load snmp module unable to load mikrotik ssh module unable to load freeBSD ssh module unable to load linux ssh module configure: add to interface 4 ip 198.19.1.1/24continue (y/n)? y ... ... ...

Thank you again.

[jlixfeld]

Hello again,

I'm wondering anyone might have a few cycles to help me out here with the MoonGen RFC2544 setup.

I'd like to use my MoonGen box as both the RFC2544 Tx and Rx device like I do with my RFC2544 testers today (i.e.: Exfo). One port being the Tx interface and one port being the Rx interface and the DUT (a simple switch) would forward the frames learned via the Tx interface to the Rx interface.

Per above, I tried to get my MoonGen box to SSH, as it is my understanding that this is required in order to have this particular RFC2544 implementation operate correctly without constant user intervention.

I've included a diagram to illustrate what I'm trying to do, but I don't think it's overly complex.

Thanks!

[emmericp]

@gallenmu

[emmericp]

the rfc2544 test is still ugly, patches welcome