Git Product home page Git Product logo

emmericp / moongen Goto Github PK

View Code? Open in Web Editor NEW
1.0K 66.0 233.0 20.62 MB

MoonGen is a fully scriptable high-speed packet generator built on DPDK and LuaJIT. It can saturate a 10 Gbit/s connection with 64 byte packets on a single CPU core while executing user-provided Lua scripts for each packet. Multi-core support allows for even higher rates. It also features precise and accurate timestamping and rate control.

License: MIT License

Shell 3.96% Lua 79.90% C++ 7.36% C 8.06% CMake 0.63% Makefile 0.10%
packet-generator lua dpdk

moongen's Introduction

TL;DR

LuaJIT + DPDK = fast and flexible packet generator for 10 Gbit/s Ethernet and beyond. MoonGen uses hardware features for accurate and precise latency measurements and rate control.

Skip to Installation and Usage if you just want to send some packets.

Detailed evaluation: Paper (IMC 2015, BibTeX entry)

MoonGen Packet Generator

MoonGen is a scriptable high-speed packet generator built on libmoon. The whole load generator is controlled by a Lua script: all packets that are sent are crafted by a user-provided script. Thanks to the incredibly fast LuaJIT VM and the packet processing library DPDK, it can saturate a 10 Gbit/s Ethernet link with 64 Byte packets while using only a single CPU core. MoonGen can achieve this rate even if each packet is modified by a Lua script. It does not rely on tricks like replaying the same buffer.

MoonGen can also receive packets, e.g., to check which packets are dropped by a system under test. As the reception is also fully under control of the user's Lua script, it can be used to implement advanced test scripts. E.g. one can use two instances of MoonGen that establish a connection with each other. This setup can be used to benchmark middle-boxes like firewalls.

MoonGen focuses on four main points:

  • High performance and multi-core scaling: > 20 million packets per second per CPU core
  • Flexibility: Each packet is crafted in real time by a user-provided Lua script
  • Precise and accurate timestamping: Timestamping with sub-microsecond precision on commodity hardware
  • Precise and accurate rate control: Reliable generation of arbitrary traffic patterns on commodity hardware

You can have a look at our slides from a talk or read our paper [1] for a more detailed discussion of MoonGen's internals.

Architecture

MoonGen is built on libmoon, a Lua wrapper for DPDK.

Users can write custom scripts for their experiments. It is recommended to make use of hard-coded setup-specific constants in your scripts. The script is the configuration, it is beside the point to write a complicated configuration interface for a script. Alternatively, there is a simplified (and less powerful) command-line interface available for quick tests.

The following diagram shows the architecture and how multi-core support is handled.

Architecture

Execution begins in the master task that must be defined in the userscript. This task configures queues and filters on the used NICs and then starts one or more slave tasks.

Note that Lua does not have any native support for multi-threading. MoonGen therefore starts a new and completely independent LuaJIT VM for each thread. The new VMs receive serialized arguments: the function to execute and arguments like the queue to send packets from. Threads only share state through the underlying library.

The example script quality-of-service-test.lua shows how this threading model can be used to implement a typical load generation task. It implements a QoS test by sending two different types of packets and measures their throughput and latency. It does so by starting two packet generation tasks: one for the background traffic and one for the prioritized traffic. A third task is used to categorize and count the incoming packets.

Hardware Timestamping

Intel commodity NICs from the igb, ixgbe, and i40e families support timestamping in hardware for both transmitted and received packets. The NICs implement this to support the IEEE 1588 PTP protocol, but this feature can be used to timestamp almost arbitrary UDP packets. MoonGen achieves a precision and accuracy of below 100 ns.

Use test-timestamping-capabilities.lua in examples/timestamping-tests to test your NIC's timestamping capabilities.

A more detailed evaluation can be found in our paper [1].

Installation

  1. Install the dependencies (see below)
  2. ./build.sh
  3. sudo ./bind-interfaces.sh
  4. sudo ./setup-hugetlbfs.sh
  5. sudo ./build/MoonGen examples/l3-load-latency.lua 0 1

Note: You need to bind NICs to DPDK to use them. bind-interfaces.sh does this for all unused NICs (no routing table entry in the system). Use libmoon/deps/dpdk/usertools/dpdk-devbind.py to manage NICs manually.
If you have secure boot enabled (by default in ubuntu 20.04 LTS), you will get a permission denied error on the insmod command of the kernel module when running sudo ./bind-interfaces.sh. You can temporarely disable secure boot on ubuntu with the steps described here to permit the unsigned driver to load.

Dependencies

  • gcc >= 4.8
  • make
  • cmake
  • libnuma-dev
  • kernel headers (for the DPDK igb-uio driver)
  • lspci (for dpdk-devbind.py)
  • additional dependencies for Mellanox NICs

Run the following command to install these on Debian/Ubuntu:

sudo apt-get install -y build-essential cmake linux-headers-`uname -r` pciutils libnuma-dev

Using MoonGen

You have to write a simple script for your use case. The example l3-load-latency.lua is a good starting point as it makes use of a lot of different features of MoonGen.

Simple CLI

The simplest way to get started is using the simple command line interface. For example:

sudo ./moongen-simple start load-latency:0:1:rate=10Mp/s,time=3m

This sends packets with a rate of 10 million packets per second for 3 minutes from port 0 to port 1 and outputs the latency at the end of the run. Available DPDK ports are printed on startup.

load-latency is a flow that is defined in flows/examples.lua. Have a look at this file to see how flows are defined. You can add your own flow definitions to any file in the flows subdirectory. Run ./moongen-simple list to see all available flows. It's also helpful to run a flow with debug instead of start to print packet contents instead of sending them.

See the documentation for the simple CLI for more details and instructions. You can also check the help command or run any subcommand with -h.

This API comes with a small performance overhead compared to the full API. You can enable multi-threading on a single port by specifying the same port multiple times separated with commas.

Using the full API

Using the full API gives you complete control over MoonGen, this is recommended for more complex test setups. This means that you'll have to write a custom script to use MoonGen in this mode.

MoonGen comes with examples in the examples folder which can be used as a basis for custom scripts. Reading the example script l3-load-latency.lua or quality-of-service-test.lua is a good way to learn more about our scripting API as these scripts uses most features of MoonGen.

You can run a script like this:

./build/MoonGen ./examples/l3-load-latency.lua 0 1

The two command line arguments are the transmission and reception ports, see script (or run with -h) for CLI parameter handling. MoonGen prints all available ports on startup, so adjust this if necessary.

You can also check out the examples of the libmoon project. All libmoon scripts are also valid MoonGen scripts as MoonGen extends libmoon.

Frequently Asked Questions

Which NICs do you support?

Basic functionality is available on all NICs supported by DPDK. Hardware timestamping is currently supported and tested on Intel igb, ixgbe, and i40e NICs. However, support for specific features vary between models. Use test-timestamping-capabilities.lua in examples/timestamping-tests to find out what your NIC supports. Hardware rate control is supported and tested on Intel ixgbe and i40e NICs.

What's the difference between MoonGen and libmoon?

MoonGen builds on libmoon by extending it with features for packet generators such as software rate control and software timestamping.

If you want to write a packet generator or test your application: use MoonGen. If you want to prototype DPDK applications: use libmoon.

References

[1] Paul Emmerich, Sebastian Gallenmüller, Daniel Raumer, Florian Wohlfart, and Georg Carle. MoonGen: A Scriptable High-Speed Packet Generator, 2015. IMC 2015. Available online. BibTeX.

moongen's People

Contributors

ackxolotl avatar adunsg avatar ap-frank avatar atheurer avatar benerudolph avatar duk3luk3 avatar emmericp avatar gallenmu avatar gierens avatar holzingk avatar katsulynx avatar kitcat420 avatar liweitianux avatar mbenitohoz avatar netronomemoongen avatar ogasser avatar pavel-odintsov avatar rainerschoe avatar reisz avatar robclu avatar robidev avatar simonwagner avatar slyon avatar sosaavedra avatar werpat avatar wrfly avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

moongen's Issues

MoonGen freezes a machine with 82598EB 10G card

Hi,

When running Moogen from git on a core i7 2600 (BIOS HT disabled) 16G RAM ubuntu 14.04 kernel 3.13 and network card :

01:00.0 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82598EB 10-Gigabit AF Dual Port Network Connection (rev 01)

01:00.0 0200: 8086:10f1 (rev 01)
Subsystem: 8086:a21f

root@t1:~/MoonGen# ./build/MoonGen ./examples/tx-multi-core.lua
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 4 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0xc00000 bytes
EAL: Virtual area found at 0x7f669d600000 (size = 0xc00000)
EAL: Ask a virtual area of 0x800000 bytes
EAL: Virtual area found at 0x7f669cc00000 (size = 0x800000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f669c800000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f669c400000 (size = 0x200000)
EAL: Ask a virtual area of 0x1b400000 bytes
EAL: Virtual area found at 0x7f6677200000 (size = 0x1b400000)
EAL: Ask a virtual area of 0x63000000 bytes
EAL: Virtual area found at 0x7f6614000000 (size = 0x63000000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f669c000000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f669bc00000 (size = 0x200000)
EAL: Requesting 1024 pages of size 2MB from socket 0
EAL: TSC frequency is ~3411484 KHz
EAL: Master core 0 is ready (tid=a19fa8c0)
EAL: Core 3 is ready (tid=9b3fe700)
EAL: Core 2 is ready (tid=9bbff700)
EAL: Core 1 is ready (tid=9eb45700)
EAL: PCI device 0000:01:00.0 on NUMA socket -1
EAL: probe driver: 8086:10f1 rte_ixgbe_pmd
EAL: 0000:01:00.0 not managed by VFIO driver, skipping
EAL: PCI memory mapped at 0x7f66a19a3000
EAL: PCI memory mapped at 0x7f66a1963000
EAL: PCI memory mapped at 0x7f66a195f000

Here machine freezes completely I have to power off and on.

On the same machine DPDK 2.2.0 (from tarball) and pktgen-dpdk (from git) work fine.

Add support for shared cores

Add support for CPU cores running more than one task/thread.
This is useful to avoid 'wasting' a CPU core for timestamping or ARP responding.

Note that this feature is on the DPDK 2.0 roadmap, so this issue will resolve itself sometime this year ;)

Implement structs for protocol headers

The structs should be implemented in include/memory.lua as a method of the pktbuf object, something like this:

pktbuf:getIPHeader()
pktbuf:getIPHeaderAtOffset()

The functions consist of a simple call to ffi.cast on the buffer.

Find a library for unit tests that works for our use case

Unit tests in MoonGen are currently written using https://github.com/Olivine-Labs/busted

However, this is far from optimal. Busted is not really suited to test a tool like MoonGen. (Even starting it with a MoonGen instead of the default Lua interpreter is very hacky, see run-tests.sh)

Also, it doesn't support testing in separate processes. We want to run each test file in a separate process for two reasons:

  • DPDK has a lot of global state and resetting DPDK is not really feasible
  • DPDK or our C code might just crash. Such crashes aren't (and can't) be properly handled by busted by design

Unfortunately, busted has decided against supporting multi-process testing: lunarmodules/busted#278

Lost timestamp packets at high data rates

Hi,
I am using MoonGen to fill a 10 Gb/s link with TCP SYN flooding, and I try to measure the latency by using the measureLatency function.
But most or all timestamp packets are lost when the load is important. I use two ports directly connected by a cable, so the loss is not due to an external equipment.
When counting packets, I see the same number of sent and received packets.
I have setup filters to get only PTP packets in the receiving loop. This way the supported load gets higher, but I still lose most or all packets at full link rate.
I do not know if packets are lost during sending or reception.

Do you have an idea of what could cause the problem?

0.1 Release

Let's do a proper release with a version number and all that stuff.

  • DPDK 2.1 support
  • shared cores for BG task (ARP...)
  • better XL710 10/40G support
  • better i350 support (HW filter)
  • better VirtIO support
  • software timestamping
  • detailed precision evaluation of timestamping and rate control
  • TCP stack
  • new test framework/infrastructure

Add support for Intel XL710 (40Gbps)

I have been trying to add support for these adapters. I use a lot of these (12 x 40Gb) in order to test for NFV workloads. We currently use pktgen-dpdk for this testing, but I'd like to move this to Moongen since it is very customizable.

I have some very basic functionality working. For example, I can use ./examples/benchmark/packet-sizes-rx.lua, but the Tx stats are wrong (Rx seems to be OK). I have not looked in to time-stamping yet.

I am wondering if anyone has code changes for XL710. If not, I have a couple small changes I can provide.

Very stranger performance degradation

Hello, folks!

I hit performance issue again ;(

I have two servers with same issue:

  1. Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
  2. Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz

Both servers uses DPDK 2.0 and Intel X520 NICs (single two port NIC per server),

I could achieve line rate with l3-tcp-syn-flood.lua some time ago. But today I have pulled all upgrades from repository and rebuild it and got performance degradation:

Sent 2542592 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.03 MBit/s wire rate
Sent 3818112 packets, current rate 12.75 Mpps, 6530.52 MBit/s, 8571.31 MBit/s wire rate
Sent 5093632 packets, current rate 12.75 Mpps, 6530.33 MBit/s, 8571.06 MBit/s wire rate
Sent 6369152 packets, current rate 12.75 Mpps, 6530.50 MBit/s, 8571.28 MBit/s wire rate

So, I tried to spread load over two queues (two logical CPUS) and haven't got success here too:

Sent 7010176 packets, current rate 6.38 Mpps, 3265.58 MBit/s, 4286.08 MBit/s wire rate
Sent 7653120 packets, current rate 6.37 Mpps, 3263.71 MBit/s, 4283.62 MBit/s wire rate

Finally, I got same generation speed near 12.75 mpps.

But with my patch #78 I could generate 24 mpps from same server:

Port 0 sent 62716672 packets, current rate 12.37 Mpps, 6332.44 MBit/s, 8311.32 MBit/s wire rate
Port 1 sent 59574144 packets, current rate 12.37 Mpps, 6333.89 MBit/s, 8313.23 MBit/s wire rate

On receiving side:

We process: 24733385 pps
We process: 24744198 pps

What's wrong here? :)

Implementing Support for other NICs

Hello,

First of all, thanks for the helping in issue #77. And sorry I couldn't reply follow on comments, I thought I would get some mailed notification for the reply, which i didn't, and hence couldn't reply your query. But you were right it was a virtual NIC.
Now we are trying to use other devices, currently we have few of these : http://www.lannerinc.com/products/x86-network-appliances/x86-desktop-appliances/fw-7525
We would like to run MoonGen on them for some network performance testing. Especially timestamping (PTP protocol). Can you advice something how we should go about it?

Regards
Sumit

Separate Lua l3-load-latency.lua test

Hi, is it possible to separate lua l3-load-latency.lua and l2-load-latency.lua into clients and servers, instead of all together?

As if maybe sending and receiving are sharing the same up/down link, they will have some interference for calculating?

More specifically, a separate server on the other side of the switch/bridge/router will be preferred.

Thanks,

wenhui

Ability to run with DPDK driver running with uio_pci_generic

Hello, folks!

I really love your toolkit =) Thank you sooo much!

But I expected very strange trouble. Every time when I reboot my server MoonGen fails after reboot:

 ulimit -c unlimited

/usr/src/MoonGen/build/MoonGen examples/l3-tcp-syn-flood.lua 0 10.0.0.1 16000000 10000
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 0 on socket 0
EAL: Detected lcore 5 as core 1 on socket 0
EAL: Detected lcore 6 as core 2 on socket 0
EAL: Detected lcore 7 as core 3 on socket 0
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f427dc00000 (size = 0x200000)
EAL: Ask a virtual area of 0xc00000 bytes
EAL: Virtual area found at 0x7f427ce00000 (size = 0xc00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f427ca00000 (size = 0x200000)
EAL: Ask a virtual area of 0x7000000 bytes
EAL: Virtual area found at 0x7f4275800000 (size = 0x7000000)
EAL: Requesting 64 pages of size 2MB from socket 0
EAL: TSC frequency is ~3066776 KHz
EAL: Master core 0 is ready (tid=806c3880)
EAL: Core 7 is ready (tid=727f9700)
EAL: Core 6 is ready (tid=72ffa700)
EAL: Core 5 is ready (tid=737fb700)
EAL: Core 4 is ready (tid=73ffc700)
EAL: Core 2 is ready (tid=74ffe700)
EAL: Core 3 is ready (tid=747fd700)
EAL: Core 1 is ready (tid=757ff700)
EAL: PCI device 0000:04:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL:   0000:04:00.0 not managed by VFIO driver, skipping
Segmentation fault (core dumped)

With following stacktrace:

gdb build/MoonGen core
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/MoonGen...done.
[New LWP 795]
[New LWP 801]
[New LWP 802]
[New LWP 796]
[New LWP 797]
[New LWP 804]
[New LWP 803]
[New LWP 799]
[New LWP 800]
[New LWP 798]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/src/MoonGen/build/MoonGen examples/l3-tcp-syn-flood.lua 0 10.0.0.1 1600000'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000491b6d in ixgbe_init_ops_generic ()
(gdb) bt
#0  0x0000000000491b6d in ixgbe_init_ops_generic ()
#1  0x0000000000496fa6 in ixgbe_init_ops_82599 ()
#2  0x000000000048ad18 in eth_ixgbe_dev_init ()
#3  0x000000000041bbae in rte_eth_dev_init ()
#4  0x0000000000431eb4 in rte_eal_pci_probe ()
#5  0x000000000042668b in rte_eal_init ()
#6  0x00007f428024c030 in ?? () from /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2
#7  0x00007f428028987a in ?? () from /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2
#8  0x00007f428029d5e6 in ?? () from /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2
#9  0x00007f4280249f33 in ?? () from /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2
#10 0x00007f428025939d in lua_pcall () from /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2
#11 0x0000000000416a64 in main (argc=6, argv=<optimized out>) at /usr/src/MoonGen/src/main.c:37
(gdb) quit

I could fix this issue with running command: bind-interfaces.sh

And I found my DPDK examples works fine with:

/usr/src/dpdk-2.0.0/tools/dpdk_nic_bind.py --bind=uio_pci_generic 04:00.0
/usr/src/dpdk-2.0.0/tools/dpdk_nic_bind.py --bind=uio_pci_generic 04:00.1

But for MoonGen I should specify igb_uio instead:

modprobe uio
/usr/src/dpdk-2.0.0/tools/dpdk_nic_bind.py --bind=igb_uio  04:00.0
/usr/src/dpdk-2.0.0/tools/dpdk_nic_bind.py --bind=igb_uio  04:00.1

Is there are any way to enable MoonGen work with uio_pci_generic?

Update to DPDK 1.8

This is unfortunately not as easy as the update from 1.6 to 1.7 as several data structures like rte_pkt_mbuf must be adapted.

Important new features:

  • larger ol_flags field for packets (CRC disable flag without overlaps, yay)
  • userdata field in mbuf: can be used for delays

example icmp-arp-responder not working

Hi,

I am trying to run the icmp-arp-responder example and it seems stuck there:

EAL: Master core 0 is ready (tid=147e2880) <==========Master core 0
EAL: Core 1 is ready (tid=8d3f2700)
EAL: PCI device 0000:04:00.0 on NUMA socket -1
EAL: probe driver: 8086:10fb rte_ixgbe_pmd
EAL: 0000:04:00.0 not managed by UIO driver, skipping
EAL: PCI device 0000:04:00.1 on NUMA socket -1 <==========managed by UIO
EAL: probe driver: 8086:10fb rte_ixgbe_pmd
EAL: PCI memory mapped at 0x7f1e1472b000
EAL: PCI memory mapped at 0x7f1e14727000
EAL: PCI device 0000:07:00.0 on NUMA socket -1
EAL: probe driver: 8086:10e8 rte_igb_pmd
EAL: 0000:07:00.0 not managed by UIO driver, skipping
EAL: PCI device 0000:07:00.1 on NUMA socket -1
EAL: probe driver: 8086:10e8 rte_igb_pmd
EAL: 0000:07:00.1 not managed by UIO driver, skipping
EAL: PCI device 0000:08:00.0 on NUMA socket -1
EAL: probe driver: 8086:10e8 rte_igb_pmd
EAL: 0000:08:00.0 not managed by UIO driver, skipping
EAL: PCI device 0000:08:00.1 on NUMA socket -1
EAL: probe driver: 8086:10e8 rte_igb_pmd
EAL: 0000:08:00.1 not managed by UIO driver, skipping
Found 1 usable ports:
Ports 0: E8:EA:6A:06:1B:1B (82599EB 10-Gigabit SFI/SFP+ Network Connection)
[WARNING] You are using a deprecated method for invoking device.config. config(...) should be used with named arguments. For details: see documentation
Waiting for ports to come up...
Port 0 (E8:EA:6A:06:1B:1B) is up: full-duplex 10000 MBit/s
1 ports are up.
[WARNING] You are trying to use [Device: id=0](attached to the CPU socket 0) from a thread on core 1 on socket 1!
[WARNING] This can significantly impact the performance or even not work at all
[WARNING] You can change the used CPU cores in dpdk-conf.lua or by using dpdk.launchLuaOnCore(core, ...)

----HANGING HERE, NO MORE OUTPUT------

I get the same warning of changing CPU cores in dpdk-conf.lua when run other example script like the tcp syn flooding and the tcp syn flooding works fine. so the warning should be irrelevant here. but I went ahead to change the CPU cores in dpdk-conf.lua to ' cores = { 0 }', then I got:

Port 0 (E8:EA:6A:06:1B:1B) is up: full-duplex 10000 MBit/s
1 ports are up.
[ERROR] Lua error in task master
lua/include/dpdk.lua:197: not enough cores to start this lua task

Stack Traceback

(2) Lua field 'launchLua' at file 'lua/include/dpdk.lua:197'
(3) Lua function 'master' at file 'examples/icmp-arp-responder.lua:24' (best guess)
Local variables:
funny = nil
port = number: 0
dev = [Device: id=0] {initialized:true, rxQueues:table: 0x40611858, txQueues:table: 0x40611880 (more...)}
(4) global C function 'xpcall'
(5) Lua upvalue 'slave' at file 'lua/include/main.lua:69'
Local variables:
_ = string: "build/MoonGen"
file = string: "examples/icmp-arp-responder.lua"
devices = table: 0x40612300 {1:table: 0x406118c8}
args = table: 0x402154f0 {1:0, 2:10.3.3.249}
(6) Lua function 'main' at file 'lua/include/main.lua:105' (best guess)
Local variables:
task = string: "master"
lua/include/dpdk.lua:197: not enough cores to start this lua task

so my question is:

1, how to change the core id so the lua script can be run on specified CPU core? tried dpdk-conf.lua and dpdk.launchLuaOnCore(core, ...). seems no effect.

2, any clue why icmp-arp-responder silently hanging there?

Thanks and appreciate the answer.

Update to DPDK 2.0

This is going to be an annoying but necessary update.

Important new features:

  • larger ol_flags field for packets (CRC disable flag without overlaps)
  • userdata field in mbuf: can be used for delays
  • new filter API, this will break our timestamp filters
  • support for shared cores (yay!)

Refactor Latency Measurements

The time stamping logic should not be in user scripts as this currently leads to a lot of duplicated code.

The whole timestamping loop should be moved into MoonGen-core.

Does moongen run in a VM?

Hi emmericp and others,

First of all, apologies, if this is the wrong place to ask questions. Anyway, we really like your moongen project, and it seems to work fine with the two 82599 Intel 10Gbit cards we have. However, In our cloud environment we would like to explore the possibility to run moongen in a VM. It would be OK to use sriov and pci-passthrough etc. features to speed things up in a VM.

  • Do you have any experience on running moongen in VM?
  • How difficult you think it would be to support VMs?
  • Do you foresee problems / performance issues in VM?

Thanks for your help.

--KimN

Fix and update example scripts

Some of the example scripts use old, outdated, and/or broken APIs since we had some changes in the API recently.

hello-world.lua is the most modern example script and all other scripts should be updated to 'look like hello-world.lua'

We also need some kind of test that runs the examples and checks if they still work as expected

Tx stats incorrect for XL710 40Gbps

There seems to be a problem with the way Tx stats are reported for Intel XL710 (fortville) 40Gbps adapters. Below is output which shows both Tx and Rx stats, with the device-under-test simply forwarding packets back to the MoonGen packet generator:

[Device: id=3] Received 14121100 packets, current rate 14.12 Mpps, 7229.98 MBit/s, 9489.35 MBit/s wire rate.
[Device: id=2] Sent 12844125 packets, current rate 12.84 Mpps, 7149.29 MBit/s, 9204.31 MBit/s wire rate.
[Device: id=3] Received 28245004 packets, current rate 14.12 Mpps, 7231.41 MBit/s, 9491.23 MBit/s wire rate.
[Device: id=2] Sent 25703720 packets, current rate 12.86 Mpps, 7158.05 MBit/s, 9215.57 MBit/s wire rate.
[Device: id=3] Received 42368237 packets, current rate 14.12 Mpps, 7231.13 MBit/s, 9490.85 MBit/s wire rate.

Generally one would not expect the packets forwarded back to exceed the transmitted packets :)

The device-under-test is using ovs-dpdk, and the stats reported from ovs-vsctl dump-ports agree with the Rx stats from MoonGen.

This is with dpdk2.0 branch and lau script found here: https://github.com/atheurer/MoonGen/blob/dpdk2.x-opnfv/examples/opnfv-vsperf.lua

Lua error in task master lua/include/device.lua:540: TX rate control not yet implemented for this NIC

wenhui@nimbnode34:~/MoonGen$ sudo ./build/MoonGen ./examples/quality-of-service-test.lua 0 1
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 8 on socket 0
EAL: Detected lcore 4 as core 9 on socket 0
EAL: Detected lcore 5 as core 10 on socket 0
EAL: Detected lcore 6 as core 0 on socket 1
EAL: Detected lcore 7 as core 1 on socket 1
EAL: Detected lcore 8 as core 2 on socket 1
EAL: Detected lcore 9 as core 8 on socket 1
EAL: Detected lcore 10 as core 9 on socket 1
EAL: Detected lcore 11 as core 10 on socket 1
EAL: Detected lcore 12 as core 0 on socket 0
EAL: Detected lcore 13 as core 1 on socket 0
EAL: Detected lcore 14 as core 2 on socket 0
EAL: Detected lcore 15 as core 8 on socket 0
EAL: Detected lcore 16 as core 9 on socket 0
EAL: Detected lcore 17 as core 10 on socket 0
EAL: Detected lcore 18 as core 0 on socket 1
EAL: Detected lcore 19 as core 1 on socket 1
EAL: Detected lcore 20 as core 2 on socket 1
EAL: Detected lcore 21 as core 8 on socket 1
EAL: Detected lcore 22 as core 9 on socket 1
EAL: Detected lcore 23 as core 10 on socket 1
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 24 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x1000000 bytes
EAL: Virtual area found at 0x7fa2b7800000 (size = 0x1000000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7fa2b7400000 (size = 0x200000)
EAL: Ask a virtual area of 0x11200000 bytes
EAL: Virtual area found at 0x7fa29b800000 (size = 0x11200000)
EAL: Ask a virtual area of 0x2d800000 bytes
EAL: Virtual area found at 0x7fa26de00000 (size = 0x2d800000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7fa2b7000000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7fa2b6c00000 (size = 0x200000)
EAL: Ask a virtual area of 0x3fc00000 bytes
EAL: Virtual area found at 0x7fa22e000000 (size = 0x3fc00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7fa2b6800000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7fa2b6400000 (size = 0x200000)
EAL: Requesting 512 pages of size 2MB from socket 0
EAL: Requesting 512 pages of size 2MB from socket 1
EAL: TSC frequency is ~2666761 KHz
EAL: Master core 0 is ready (tid=bbe04880)
EAL: Core 7 is ready (tid=b33f9700)
EAL: Core 8 is ready (tid=b2bf8700)
EAL: Core 9 is ready (tid=b23f7700)
EAL: Core 10 is ready (tid=b1bf6700)
EAL: Core 11 is ready (tid=b13f5700)
EAL: Core 12 is ready (tid=b0bf4700)
EAL: Core 6 is ready (tid=b3bfa700)
EAL: Core 13 is ready (tid=b03f3700)
EAL: Core 14 is ready (tid=afbf2700)
EAL: Core 15 is ready (tid=af3f1700)
EAL: Core 16 is ready (tid=aebf0700)
EAL: Core 17 is ready (tid=ae3ef700)
EAL: Core 18 is ready (tid=adbee700)
EAL: Core 19 is ready (tid=ad3ed700)
EAL: Core 5 is ready (tid=b43fb700)
EAL: Core 4 is ready (tid=b4bfc700)
EAL: Core 20 is ready (tid=2dfff700)
EAL: Core 21 is ready (tid=2d7fe700)
EAL: Core 22 is ready (tid=2cffd700)
EAL: Core 23 is ready (tid=2c7fc700)
EAL: Core 3 is ready (tid=b53fd700)
EAL: Core 2 is ready (tid=b5bfe700)
EAL: Core 1 is ready (tid=b63ff700)
EAL: PCI device 0000:05:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10c9 rte_igb_pmd
EAL:   0000:05:00.0 not managed by VFIO driver, skipping
EAL:   0000:05:00.0 not managed by UIO driver, skipping
EAL: PCI device 0000:05:00.1 on NUMA socket -1
EAL:   probe driver: 8086:10c9 rte_igb_pmd
EAL:   0000:05:00.1 not managed by VFIO driver, skipping
EAL:   0000:05:00.1 not managed by UIO driver, skipping
EAL: PCI device 0000:07:00.0 on NUMA socket -1
EAL:   probe driver: 8086:1572 rte_i40e_pmd
EAL:   0000:07:00.0 not managed by VFIO driver, skipping
EAL:   PCI memory mapped at 0x7fa22b7fc000
EAL:   PCI memory mapped at 0x7fa2bbdc5000
EAL: PCI device 0000:07:00.1 on NUMA socket -1
EAL:   probe driver: 8086:1572 rte_i40e_pmd
EAL:   0000:07:00.1 not managed by VFIO driver, skipping
EAL:   PCI memory mapped at 0x7fa22affc000
EAL:   PCI memory mapped at 0x7fa2bbdbd000
[INFO]  Found 2 usable devices:
   Device 0: 68:05:CA:30:52:F4 (unknown NIC (PCI ID 8086:1572))
   Device 1: 68:05:CA:30:52:F5 (unknown NIC (PCI ID 8086:1572))
**[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.**
[INFO]  Waiting for devices to come up...
[INFO]  Device 0 (68:05:CA:30:52:F4) is up: full-duplex 10000 MBit/s
[INFO]  Device 1 (68:05:CA:30:52:F5) is DOWN: 0 MBit/s
[INFO]  1 devices are up.
[INFO]  Sending 1500 MBit/s background traffic to UDP port 43
[INFO]  Sending 100 MBit/s foreground traffic to UDP port 42
**[FATAL] Lua error in task master
lua/include/device.lua:540: TX rate control not yet implemented for this NIC**
Stack Traceback
===============
(2) Lua method 'fatal' at file 'lua/include/log.lua:129'
    Local variables:
     self = table: 0x4081b020  {DEBUG:0, fatal:function: 0x40815450, writeToLog:function: 0x408116f0, INFO:1 (more...)}
     str = string: "TX rate control not yet implemented for this NIC"
(3) Lua method 'setRate' at file 'lua/include/device.lua:540'
    Local variables:
     self = [TxQueue: id=0, qid=0]  {id:0, rate:0.66533396559011, qid:0, dev:[Device: id=0], speed:10000}
     rate = number: 1500
(4) Lua function 'master' at file './examples/quality-of-service-test.lua:49' (best guess)
    Local variables:
     txPort = number: 0
     rxPort = number: 1
     bgRate = number: 1500
     fgRate = number: 100
     txDev = [Device: id=0]  {initialized:true, rxQueues:table: 0x40a5fd10, txQueues:table: 0x40a5fd38 (more...)}
     rxDev = [Device: id=1]  {initialized:true, rxQueues:table: 0x40a600a0, txQueues:table: 0x40a600c8 (more...)}
(5) global C function 'xpcall'
(6) Lua upvalue 'slave' at file 'lua/include/main.lua:107'
    Local variables:
     _ = string: "./build/MoonGen"
     file = string: "./examples/quality-of-service-test.lua"
     _ = nil
     cfgfile = nil
     devices = table: 0x40a5fc38  {1:table: 0x40a5fd80, 2:table: 0x40a600f0}
     args = table: 0x40a60820  {1:0, 2:1}
(7) Lua function 'main' at file 'lua/include/main.lua:143' (best guess)
    Local variables:
     task = string: "master"
    lua/include/device.lua:540: TX rate control not yet implemented for this NIC
wenhui@nimbnode34:~/MoonGen$ 

Probably an misprint in device.lua

Hi!

There is following string in file device.lua, line 276:
if rate >= (64 * 64) / (84 * 84) and rate < 1 then

Variable "rate" is a quotient of rate function argument and wire speed maximum rate.
Should there be just "64 / 84" instead of "(64 * 64) / (84 * 84)"?

Core Mask for Multicore Performance

Hi, sorry for interruption, yet I was wondering how to mask Moongen to multicore please? "sudo ./build/MoonGen -c 7 ./examples/l2-load-latency.lua 0 0 10000 " does not work here.

MoonGen doesn't generate packets

Hi Paul Emmerich,
I'm trying to use MooGen to generate packets on Fedora 21, kernel 3.17.4-301-fc21.
After building as intructions, the test run as
./MoonGen ../examples/l2-load-latency.lua 0 1
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 8 on socket 0
EAL: Detected lcore 6 as core 9 on socket 0
EAL: Detected lcore 7 as core 10 on socket 0
EAL: Detected lcore 8 as core 11 on socket 0
EAL: Detected lcore 9 as core 16 on socket 0
EAL: Detected lcore 10 as core 17 on socket 0
EAL: Detected lcore 11 as core 18 on socket 0
EAL: Detected lcore 12 as core 19 on socket 0
EAL: Detected lcore 13 as core 20 on socket 0
EAL: Detected lcore 14 as core 24 on socket 0
EAL: Detected lcore 15 as core 25 on socket 0
EAL: Detected lcore 16 as core 26 on socket 0
EAL: Detected lcore 17 as core 27 on socket 0
EAL: Detected lcore 18 as core 0 on socket 1
EAL: Detected lcore 19 as core 1 on socket 1
EAL: Detected lcore 20 as core 2 on socket 1
EAL: Detected lcore 21 as core 3 on socket 1
EAL: Detected lcore 22 as core 4 on socket 1
EAL: Detected lcore 23 as core 8 on socket 1
EAL: Detected lcore 24 as core 9 on socket 1
EAL: Detected lcore 25 as core 10 on socket 1
EAL: Detected lcore 26 as core 11 on socket 1
EAL: Detected lcore 27 as core 16 on socket 1
EAL: Detected lcore 28 as core 17 on socket 1
EAL: Detected lcore 29 as core 18 on socket 1
EAL: Detected lcore 30 as core 19 on socket 1
EAL: Detected lcore 31 as core 20 on socket 1
EAL: Detected lcore 32 as core 24 on socket 1
EAL: Detected lcore 33 as core 25 on socket 1
EAL: Detected lcore 34 as core 26 on socket 1
EAL: Detected lcore 35 as core 27 on socket 1
EAL: Detected lcore 36 as core 0 on socket 0
EAL: Detected lcore 37 as core 1 on socket 0
EAL: Detected lcore 38 as core 2 on socket 0
EAL: Detected lcore 39 as core 3 on socket 0
EAL: Detected lcore 40 as core 4 on socket 0
EAL: Detected lcore 41 as core 8 on socket 0
EAL: Detected lcore 42 as core 9 on socket 0
EAL: Detected lcore 43 as core 10 on socket 0
EAL: Detected lcore 44 as core 11 on socket 0
EAL: Detected lcore 45 as core 16 on socket 0
EAL: Detected lcore 46 as core 17 on socket 0
EAL: Detected lcore 47 as core 18 on socket 0
EAL: Detected lcore 48 as core 19 on socket 0
EAL: Detected lcore 49 as core 20 on socket 0
EAL: Detected lcore 50 as core 24 on socket 0
EAL: Detected lcore 51 as core 25 on socket 0
EAL: Detected lcore 52 as core 26 on socket 0
EAL: Detected lcore 53 as core 27 on socket 0
EAL: Detected lcore 54 as core 0 on socket 1
EAL: Detected lcore 55 as core 1 on socket 1
EAL: Detected lcore 56 as core 2 on socket 1
EAL: Detected lcore 57 as core 3 on socket 1
EAL: Detected lcore 58 as core 4 on socket 1
EAL: Detected lcore 59 as core 8 on socket 1
EAL: Detected lcore 60 as core 9 on socket 1
EAL: Detected lcore 61 as core 10 on socket 1
EAL: Detected lcore 62 as core 11 on socket 1
EAL: Detected lcore 63 as core 16 on socket 1
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 64 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x3fc00000 bytes
EAL: Virtual area found at 0x7f9996600000 (size = 0x3fc00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f99e2c00000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f99e2800000 (size = 0x200000)
EAL: Requesting 512 pages of size 2MB from socket 1
EAL: TSC frequency is ~2300000 KHz
EAL: Master core 63 is ready (tid=e55d7840)
EAL: PCI device 0000:01:00.0 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: 0000:01:00.0 not managed by VFIO driver, skipping
EAL: 0000:01:00.0 not managed by UIO driver, skipping
EAL: PCI device 0000:01:00.1 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: 0000:01:00.1 not managed by VFIO driver, skipping
EAL: 0000:01:00.1 not managed by UIO driver, skipping
EAL: PCI device 0000:01:00.2 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: 0000:01:00.2 not managed by VFIO driver, skipping
EAL: 0000:01:00.2 not managed by UIO driver, skipping
EAL: PCI device 0000:01:00.3 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: 0000:01:00.3 not managed by VFIO driver, skipping
EAL: 0000:01:00.3 not managed by UIO driver, skipping
EAL: PCI device 0000:81:00.0 on NUMA socket 1
EAL: probe driver: 8086:10fb rte_ixgbe_pmd
EAL: 0000:81:00.0 not managed by VFIO driver, skipping
EAL: PCI memory mapped at 0x7f99e5521000
EAL: PCI memory mapped at 0x7f99e55df000
EAL: PCI device 0000:81:00.1 on NUMA socket 1
EAL: probe driver: 8086:10fb rte_ixgbe_pmd
EAL: 0000:81:00.1 not managed by VFIO driver, skipping
EAL: PCI memory mapped at 0x7f99e54a1000
EAL: PCI memory mapped at 0x7f99e549d000
Found 2 usable ports:
Ports 0: 90:E2:BA:7C:3C:7C (82599EB 10-Gigabit SFI/SFP+ Network Connection)
Ports 1: 90:E2:BA:7C:3C:7D (82599EB 10-Gigabit SFI/SFP+ Network Connection)
Waiting for ports to come up...
Port 0 (90:E2:BA:7C:3C:7C) is up: full-duplex 10000 MBit/s
Port 1 (90:E2:BA:7C:3C:7D) is up: full-duplex 10000 MBit/s

It hangout here, nothing happen.
I had tried to change the source/destination MAC in the l2-load-latency.lua at function loadSlave(port, queue)
--Source MAC address
data[0] = 0x90;
data[1] = 0xe2;
data[2] = 0xba;
data[3] = 0x7c;
data[4] = 0x3c;
data[5] = 0x7c;

--Destination MAC address (this is the MAC address of NIC in DUT device)
data[6] = 0x90;
data[7] = 0xe2;
data[8] = 0xba;
data[9] = 0x7c;
data[10] = 0x30;
data[11] = 0xcc;

But the issue is remained.
Could you please give me some hints?
Thank and Best Regards.
Lap

Issue with l3-tcp-syn when we use only single port

But there are some issue with new parser code in case of single port:

MoonGen examples/l3-tcp-syn-flood.lua 0 10.0.0.1 16000000 10000

Found 2 usable ports:
   Ports 0: 90:E2:BA:78:26:8C (82599EB 10-Gigabit SFI/SFP+ Network Connection)
   Ports 1: 90:E2:BA:78:26:8D (82599EB 10-Gigabit SFI/SFP+ Network Connection)
[ERROR] Lua error in task master
examples/l3-tcp-syn-flood.lua:15: attempt to index local 'txPorts' (a number value)
Stack Traceback
===============
(2) global C function 'xpcall'
(3) Lua upvalue 'slave' at file 'lua/include/main.lua:63'
    Local variables:
     _ = string: "/usr/src/MoonGen/build/MoonGen"
     file = string: "examples/l3-tcp-syn-flood.lua"
     devices = table: 0x4127bd78  {1:table: 0x4127bec0, 2:table: 0x41267698}
     args = table: 0x412682d8  {1:0, 2:10.0.0.1, 3:16000000, 4:10000}
(4) Lua function 'main' at file 'lua/include/main.lua:99' (best guess)
    Local variables:
     task = string: "master"
    examples/l3-tcp-syn-flood.lua:15: attempt to index local 'txPorts' (a number value)

But with multiple ports all working well:

/usr/src/MoonGen/build/MoonGen examples/l3-tcp-syn-flood.lua 0,1 10.0.0.1 16000000 10000
[Device: id=0] Sent 113336547 packets, current rate 14.15 Mpps, 7242.81 MBit/s, 9506.18 MBit/s wire rate.
[Device: id=1] Sent 113143777 packets, current rate 14.14 Mpps, 7240.99 MBit/s, 9503.80 MBit/s wire rate.

RSS hash for TCP/UDP in IPv6 variant misspelled

From device.c file, it looks like tcp/udp misspelled...

if(hash_functions->udp_ipv6){
rss_hash_functions |= ETH_RSS_IPV6_TCP;
//printf("ipv6 udp\n");
}
if(hash_functions->tcp_ipv6){
rss_hash_functions |= ETH_RSS_IPV6_UDP;
//printf("ipv6 tcp\n");
}

Performance degradation, can't achieve more than 12.75 mpps

Hello, Paul!

I tested your toolkit and found it awesome! :) Nice work!

But I can't achieve speed more than 12.75 mpps with syn flood generation on ixgbe card:

build/MoonGen examples/l3-tcp-syn-flood.lua 5 10.0.0.1 16000000 10000

Output here:

Sent 465553792 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.02 MBit/s wire rate
Sent 466829312 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.01 MBit/s wire rate
Sent 468104832 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.02 MBit/s wire rate
Sent 469380352 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.02 MBit/s wire rate
Sent 470655872 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.02 MBit/s wire rate
Sent 471931392 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.02 MBit/s wire rate
Sent 473206912 packets, current rate 12.75 Mpps, 6530.30 MBit/s, 8571.02 MBit/s wire rate

From receiving side (builded with netmap) numbers are same:

319.001576 main_thread [1448] 12177834 pps (12190292 pkts in 1001023 usec)
320.002597 main_thread [1448] 12176882 pps (12189315 pkts in 1001021 usec)
321.003613 main_thread [1448] 12175354 pps (12187724 pkts in 1001016 usec)
322.004634 main_thread [1448] 12187307 pps (12199738 pkts in 1001020 usec)
323.005654 main_thread [1448] 12175676 pps (12188107 pkts in 1001021 usec)
324.006671 main_thread [1448] 12181778 pps (12194167 pkts in 1001017 usec)
325.007688 main_thread [1448] 12171620 pps (12183999 pkts in 1001017 usec)

perf top snapshot:

Samples: 277K of event 'cycles', Event count (approx.): 21570454368
  55.60%  MoonGen                  [.] ixgbe_xmit_pkts
  16.91%  MoonGen                  [.] alloc_mbuf
   9.48%  MoonGen                  [.] rte_delay_us
   5.52%  MoonGen                  [.] calc_ipv4_pseudo_header_checksums
   1.15%  MoonGen                  [.] send_all_packets

htop:

 1  [                                                                0.0%]     Tasks: 27, 62 thr, 59 kthr; 2 running
  2  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Load average: 0.11 0.21 0.41 
  3  [|                                                               0.5%]     Uptime: 3 days, 05:50:08
  4  [                                                                0.0%]
  Mem[||||||                                                   694/32205MB]
  Swp[                                                            0/8190MB]

I'm using Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz, DPDK 2.0.0. Could you help me?

Investigate negative timestamps

Some NICs like the X520/82599 forget to timestamps packets at high rates sometimes. They then lie about the timestamp flag being present. (see issue #91)

These cases should already be filtered by the timestamping receive code, but there are some reports of negative timestamps... which shouldn't happen.

However, I haven't been able to reproduce this; I've never gotten a negative timestamp from any of my scripts on any server :/

Can't run MoonGen with absolute path

Hello!

I use MoonGen so often and want to run it with absolute path. But I can't:

/usr/src/MoonGen/build/MoonGen /usr/src/MoonGen/examples/l3-tcp-syn-flood.lua 0 10.0.0.1 16000000 10000
Could not run main script: [string "require 'main'"]:1: module 'main' not found:
    no field package.preload['main']
    no file './main.lua'
    no file '/usr/local/share/luajit-2.1.0-alpha/main.lua'
    no file '/usr/local/share/lua/5.1/main.lua'
    no file '/usr/local/share/lua/5.1/main/init.lua'
    no file 'lua/include/main.lua'
    no file 'lua/include/main/init.lua'
    no file 'lua/include/lib/main.lua'
    no file 'lua/include/lib/main/init.lua'
    no file '../lua/include/main.lua'
    no file '../lua/include/main/init.lua'
    no file '../lua/include/lib/main.lua'
    no file '../lua/include/lib/main/init.lua'
    no file '../../lua/include/main.lua'
    no file '../../lua/include/main/init.lua'
    no file '../../lua/include/lib/main.lua'
    no file '../../lua/include/lib/main/init.lua'
    no file './main.so'
    no file '/usr/local/lib/lua/5.1/main.so'
    no file '/usr/local/lib/lua/5.1/loadall.so'
Lua error: attempt to call a nil value

When I switching to home folder for MoonGen it started correctly:

cd /usr/src/MoonGen/build
./MoonGen /usr/src/MoonGen/examples/l3-tcp-syn-flood.lua 0 10.0.0.1 16000000 10000
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 0 on socket 0
EAL: Detected lcore 5 as core 1 on socket 0
EAL: Detected lcore 6 as core 2 on socket 0
EAL: Detected lcore 7 as core 3 on socket 0
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f9304a00000 (size = 0x200000)
EAL: Ask a virtual area of 0xc00000 bytes
EAL: Virtual area found at 0x7f9303c00000 (size = 0xc00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7f9303800000 (size = 0x200000)
EAL: Ask a virtual area of 0x7000000 bytes
EAL: Virtual area found at 0x7f92fc600000 (size = 0x7000000)
EAL: Requesting 64 pages of size 2MB from socket 0
EAL: TSC frequency is ~3066776 KHz
EAL: Master core 0 is ready (tid=7490880)
EAL: Core 7 is ready (tid=f95f9700)
EAL: Core 6 is ready (tid=f9dfa700)
EAL: Core 5 is ready (tid=fa5fb700)
EAL: Core 4 is ready (tid=fadfc700)
EAL: Core 3 is ready (tid=fb5fd700)
EAL: Core 2 is ready (tid=fbdfe700)
EAL: Core 1 is ready (tid=fc5ff700)
EAL: PCI device 0000:04:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL:   0000:04:00.0 not managed by VFIO driver, skipping
EAL:   PCI memory mapped at 0x7f9307357000
EAL:   PCI memory mapped at 0x7f9307499000
EAL: PCI device 0000:04:00.1 on NUMA socket -1
EAL:   probe driver: 8086:10fb rte_ixgbe_pmd
EAL:   0000:04:00.1 not managed by VFIO driver, skipping
EAL:   PCI memory mapped at 0x7f93072d7000
EAL:   PCI memory mapped at 0x7f9307455000
^CEAL: PCI device 0000:05:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10d3 rte_em_pmd
EAL:   0000:05:00.0 not managed by VFIO driver, skipping
EAL:   0000:05:00.0 not managed by UIO driver, skipping
Found 2 usable ports:
   Ports 0: 90:E2:BA:78:26:8C (82599EB 10-Gigabit SFI/SFP+ Network Connection)
   Ports 1: 90:E2:BA:78:26:8D (82599EB 10-Gigabit SFI/SFP+ Network Connection)
Port 0 (90:E2:BA:78:26:8C) is up: full-duplex 10000 MBit/s
INFO: Detected in IPv4 address.
[Device: id=0] Sent 0 packets with 0 bytes payload (including CRC).
[Device: id=0] Sent nan (StdDev 0.000000) Mpps, nan (StdDev 0.000000) MBit/s, nan (StdDev 0.000000) MBit/s wire rate on average.
NYI: reclaim mempool cdata<struct mempool *>: 0x7f92fcae08c0

Could you add fix for this issue?

error: ‘struct rte_mbuf’ has no member named ‘pkt’

Hello, team!

I can't compile MoonGen from GitHub:

./build.sh 
==== Building LuaJIT 2.1.0-alpha ====
make -C src
make[1]: Entering directory '/usr/src/MoonGen/deps/luajit/src'
make[1]: Nothing to be done for 'default'.
make[1]: Leaving directory '/usr/src/MoonGen/deps/luajit/src'
==== Successfully built LuaJIT 2.1.0-alpha ====
==== Installing LuaJIT 2.1.0-alpha to /usr/local ====
mkdir -p /usr/src/MoonGen/deps/luajit/usr/local/bin /usr/src/MoonGen/deps/luajit/usr/local/lib /usr/src/MoonGen/deps/luajit/usr/local/include/luajit-2.1 /usr/src/MoonGen/deps/luajit/usr/local/share/man/man1 /usr/src/MoonGen/deps/luajit/usr/local/lib/pkgconfig /usr/src/MoonGen/deps/luajit/usr/local/share/luajit-2.1.0-alpha/jit /usr/src/MoonGen/deps/luajit/usr/local/share/lua/5.1 /usr/src/MoonGen/deps/luajit/usr/local/lib/lua/5.1
cd src && install -m 0755 luajit /usr/src/MoonGen/deps/luajit/usr/local/bin/luajit-2.1.0-alpha
cd src && test -f libluajit.a && install -m 0644 libluajit.a /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.a || :
rm -f /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2.1.0 /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so
cd src && test -f libluajit.so && \
  install -m 0755 libluajit.so /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so.2.1.0 && \
  ldconfig -n /usr/src/MoonGen/deps/luajit/usr/local/lib && \
  ln -sf libluajit-5.1.so.2.1.0 /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so && \
  ln -sf libluajit-5.1.so.2.1.0 /usr/src/MoonGen/deps/luajit/usr/local/lib/libluajit-5.1.so || :
cd etc && install -m 0644 luajit.1 /usr/src/MoonGen/deps/luajit/usr/local/share/man/man1
cd etc && sed -e "s|^prefix=.*|prefix=/usr/local|" -e "s|^multilib=.*|multilib=lib|" luajit.pc > luajit.pc.tmp && \
  install -m 0644 luajit.pc.tmp /usr/src/MoonGen/deps/luajit/usr/local/lib/pkgconfig/luajit.pc && \
  rm -f luajit.pc.tmp
cd src && install -m 0644 lua.h lualib.h lauxlib.h luaconf.h lua.hpp luajit.h /usr/src/MoonGen/deps/luajit/usr/local/include/luajit-2.1
cd src/jit && install -m 0644 bc.lua bcsave.lua dump.lua p.lua v.lua zone.lua dis_x86.lua dis_x64.lua dis_arm.lua dis_ppc.lua dis_mips.lua dis_mipsel.lua vmdef.lua /usr/src/MoonGen/deps/luajit/usr/local/share/luajit-2.1.0-alpha/jit
==== Successfully installed LuaJIT 2.1.0-alpha to /usr/local ====

Note: the development releases deliberately do NOT install a symlink for luajit
You can do this now by running this command (with sudo):

  ln -sf luajit-2.1.0-alpha /usr/src/MoonGen/deps/luajit/usr/local/bin/luajit

================== Installing x86_64-native-linuxapp-gcc
make[5]: Nothing to be done for 'depdirs'.
Configuration done
== Build lib
== Build lib/librte_compat
== Build lib/librte_eal
== Build lib/librte_net
== Build lib/librte_eal/common
== Build lib/librte_eal/linuxapp
== Build lib/librte_eal/linuxapp/igb_uio
== Build lib/librte_eal/linuxapp/eal
make[1]: Entering directory `/usr/src/linux-headers-3.16.0-4-amd64'
== Build lib/librte_eal/linuxapp/kni
make[1]: Entering directory `/usr/src/linux-headers-3.16.0-4-amd64'
(cat /dev/null;   echo kernel//usr/src/MoonGen/deps/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko;) > /usr/src/MoonGen/deps/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/igb_uio/modules.order
  Building modules, stage 2.
  MODPOST 1 modules
(cat /dev/null;   echo kernel//usr/src/MoonGen/deps/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/rte_kni.ko;) > /usr/src/MoonGen/deps/dpdk/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/modules.order
  Building modules, stage 2.
  MODPOST 1 modules
== Build lib/librte_malloc
== Build lib/librte_timer
== Build lib/librte_cfgfile
== Build lib/librte_kvargs
== Build lib/librte_jobstats
== Build lib/librte_meter
== Build lib/librte_power
== Build lib/librte_cmdline
== Build lib/librte_acl
== Build lib/librte_hash
== Build lib/librte_lpm
== Build lib/librte_ring
== Build lib/librte_mempool
== Build lib/librte_mbuf
== Build lib/librte_ether
== Build lib/librte_sched
== Build lib/librte_distributor
== Build lib/librte_reorder
== Build lib/librte_pmd_ixgbe
== Build lib/librte_pmd_i40e
== Build lib/librte_pmd_fm10k
== Build lib/librte_pmd_enic
== Build lib/librte_pmd_e1000
== Build lib/librte_pmd_bond
== Build lib/librte_pmd_ring
== Build lib/librte_pmd_af_packet
== Build lib/librte_pmd_virtio
== Build lib/librte_pmd_vmxnet3
== Build lib/librte_pmd_null
== Build lib/librte_ip_frag
== Build lib/librte_kni
== Build lib/librte_port
== Build lib/librte_table
== Build lib/librte_pipeline
== Build app
== Build app/test
== Build app/test-acl
== Build app/test-pmd
== Build app/test-pipeline
== Build app/cmdline_test
== Build app/dump_cfg
Build complete
Could not find any inactive interfaces to bind to DPDK. Note that this script does not bind interfaces that are in use by the OS.
Delete IP addresses from interfaces you would like to use with MoonGen and run this script again.
You can also use the script dpdk_nic_bind.py in deps/dpdk/tools manually to manage interfaces used by MoonGen and the OS.
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/src/MoonGen/build
[  9%] Building C object CMakeFiles/MoonGen.dir/src/memory.c.o
/usr/src/MoonGen/src/memory.c: In function ‘alloc_mbufs’:
/usr/src/MoonGen/src/memory.c:41:6: error: ‘struct rte_mbuf’ has no member named ‘pkt’
   buf->pkt.pkt_len = pkt_len;
      ^
/usr/src/MoonGen/src/memory.c:42:6: error: ‘struct rte_mbuf’ has no member named ‘pkt’
   buf->pkt.data_len = pkt_len;
      ^
CMakeFiles/MoonGen.dir/build.make:77: recipe for target 'CMakeFiles/MoonGen.dir/src/memory.c.o' failed
make[2]: *** [CMakeFiles/MoonGen.dir/src/memory.c.o] Error 1
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/MoonGen.dir/all' failed
make[1]: *** [CMakeFiles/MoonGen.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

Add support for Intel X520

I have X520 adapters, which I have tested with a couple small changes, and it appears to work just fine. I will submit pull request shortly

Some topic on decode.

"MoonGen is a fully scriptable high-speed packet generator" and the system is good to generate pcap.
I wonder this architecture is good for capture pcap and decode protocol (using lua scripts)?

How to fill in UDP data for UDP packet?

Hi

in lua/include/proto/udp.lua, I couldn't figure out how to fill in the UDP data other than the UDP headers. for example, I copied examples/l3-tcp-syn-flood.lua and changed it to use UDP as some kind of UDP flooding test, but I also want to be able to fill in some UDP data bytes like some canned bytes and send that UDP packet out, can you give me clue how to to do that?

with the modified l3-tcp-syn-flood for UDP as below:

local dpdk              = require "dpdk"
local memory    = require "memory"
local device    = require "device"
local stats             = require "stats"


function master(txPorts, minIp, numIps, rate)
        if not txPorts then
                printf("usage: txPort1[,txPort2[,...]] [minIP numIPs rate]")
                return
        end
        txPorts = tostring(txPorts)
        minIp = minIp or "10.0.0.1"
        numIps = numIps or 100
        rate = rate or 0
        for currentTxPort in txPorts:gmatch("(%d+),?") do
                currentTxPort = tonumber(currentTxPort)
                local txDev = device.config({ port = currentTxPort })
                txDev:wait()
                txDev:getTxQueue(0):setRate(rate)
                dpdk.launchLua("loadSlave", currentTxPort, 0, minIp, numIps)
        end
        dpdk.waitForSlaves()
end

function loadSlave(port, queue, minA, numIPs)
        --- parse and check ip addresses

        local minIP, ipv4 = parseIPAddress(minA)
        if minIP then
                printf("INFO: Detected an %s address.", minIP and "IPv4" or "IPv6")
        else
                errorf("ERROR: Invalid minIP: %s", minA)
        end

        -- min TCP packet size for IPv6 is 74 bytes (+ CRC)
        local packetLen = ipv4 and 60 or 74

        --continue normally
        local queue = device.get(port):getTxQueue(queue)
        local mem = memory.createMemPool(function(buf)
                buf:getUdpPacket(ipv4):fill{
                        ethSrc="a0:36:9f:a1:4d:6d", ethDst="52:54:00:2E:62:A2",
                        --- ip4Dst="10.9.1.2",
                        ip4Dst="10.9.3.6",
                        ip6Dst="fd06::1",
                        udpDst="9999",
                        udpSrc="1029",
                        pktLength=packetLen }
        end)

        local lastPrint = dpdk.getTime()
        local totalSent = 0
        local lastTotal = 0
        local lastSent = 0
        local bufs = mem:bufArray(128)
        local counter = 0
        local c = 0

        local txStats = stats:newDevTxCounter(queue, "plain")
        while dpdk.running() do
                -- faill packets and set their size
                bufs:alloc(packetLen)
                for i, buf in ipairs(bufs) do
                        local pkt = buf:getUdpPacket(ipv4)

                        --increment IP
                        if ipv4 then
                                pkt.ip4.src:set(minIP)
                                pkt.ip4.src:add(counter)
                                --random udp source port
--                              pkt.udp.src = math.random(0, 2^16 - 1)
                        else
                                pkt.ip6.src:set(minIP)
                                pkt.ip6.src:add(counter)
                        end
                        counter = incAndWrap(counter, numIPs)

                        -- dump first 3 packets
                        if c < 3 then
                                buf:dump()
                                c = c + 1
                        end
                end
                --offload checksums to NIC
                bufs:offloadTcpChecksums(ipv4)

                totalSent = totalSent + queue:send(bufs)
                txStats:update()
        end
        txStats:finalize()
end

from wireshark, I see there is

User Datagram Protocol, Src Port: 1029 (1029), Dst Port: 9999 (9999)
Data (18 bytes)
Data: 0000000000000000bd910000000000000000

I am wondering if I can fill in data bytes I wanted to fill in UDP packet.

802.1Q VLAN support

I started looking at adding VLAN support to MoonGen. Any suggestions?

It seems that the right way is to

  • Add a new header "802.1Q Ethernet header" to headers.lua
  • Modify proto/ethernet.lua so that if a VLAN tag is defined, then pkt.getEthernetPacket will use the 802.1Q_Ethernet_header instead of Ethernet_header
  • Add to proto/ethernet.lua functions getVLAN and setVLAN
  • Make sure that if the fill function has a VLAN tag, then the type is set to 0x8100

Do we need to allow the use case that someone creates an Ethernet packet and then adds a VLAN tag to it? This would probably require copying the packet from old ethernet_header to new 802.1Q_Ethernet_header

Device configuration issue in lua script

Hello,

I was trying to use MoonGen. I however had some trouble in running quality-of-service-test.lua script. IThough everything has built successfully. My nics are bind to dpdk but while running the script it says :

[WARNING] You are using a depreciated method for invoking device config. config(...) should be used with named arguments. For details review the file 'device.lua'
[ERROR] Lua error in task master
lua/include/device.lua:180: could not configure device 0: error -22

Stack Traceback

(2) Lua global 'errorf' at file 'lua/include/utils.lua:11'
Local variables:
str = string: "could not configure device %d: error %d"
(3) Lua field 'config' at file 'lua/include/device.lua:180'
Local variables:
args = table: 0x41443f28 {1:0, 2:2, 3:3, rxQueues:2, rssNQueues:0, speed:0, dropEnable:true, txDescs:256 (more...)}
rss_enabled = number: 0
rc = number: -22
(4) Lua function 'master' at file 'examples/quality-of-service-test.lua:34' (best guess)
Local variables:
txPort = number: 0
rxPort = number: 0
bgRate = number: 100
fgRate = number: 10
txDev = nil
rxDev = nil
(5) global C function 'xpcall'
(6) Lua upvalue 'slave' at file 'lua/include/main.lua:63'
Local variables:
_ = string: "./build/MoonGen"
file = string: "examples/quality-of-service-test.lua"
devices = table: 0x4079b890 {1:table: 0x4079b9d8, 2:table: 0x40ebbbb8, 3:table: 0x4198db78}
args = table: 0x4198ddc8 {1:0, 2:0, 3:100, 4:10}
(7) Lua function 'main' at file 'lua/include/main.lua:99' (best guess)
Local variables:
task = string: "master"
lua/include/device.lua:180: could not configure device 0: error -22

Can you help me with what is the issue here?

run quality-of-service-test.lua example met error.

engine@engine:~/Git/MoonGen$ sudo ./build/MoonGen ./examples/quality-of-service-test.lua 0 1
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 2 lcore(s)
EAL: cannot open VFIO container, error 2 (No such file or directory)
EAL: VFIO support could not be initialized
EAL: Setting up memory...
EAL: Ask a virtual area of 0xb800000 bytes
EAL: Virtual area found at 0x7ff10fc00000 (size = 0xb800000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7ff10f800000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7ff10f400000 (size = 0x200000)
EAL: Ask a virtual area of 0x3c00000 bytes
EAL: Virtual area found at 0x7ff10b600000 (size = 0x3c00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7ff10b200000 (size = 0x200000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7ff10ae00000 (size = 0x200000)
EAL: Ask a virtual area of 0x3400000 bytes
EAL: Virtual area found at 0x7ff107800000 (size = 0x3400000)
EAL: Ask a virtual area of 0x400000 bytes
EAL: Virtual area found at 0x7ff107200000 (size = 0x400000)
EAL: Ask a virtual area of 0x3c00000 bytes
EAL: Virtual area found at 0x7ff103400000 (size = 0x3c00000)
EAL: Ask a virtual area of 0x200000 bytes
EAL: Virtual area found at 0x7ff103000000 (size = 0x200000)
EAL: Requesting 185 pages of size 2MB from socket 0
EAL: TSC frequency is ~2599187 KHz
EAL: Master core 0 is ready (tid=1d503880)
EAL: Core 1 is ready (tid=2fff700)
EAL: PCI device 0000:02:01.0 on NUMA socket -1
EAL: probe driver: 8086:100f rte_em_pmd
EAL: 0000:02:01.0 not managed by UIO driver, skipping
EAL: PCI device 0000:03:00.0 on NUMA socket -1
EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL: PCI memory mapped at 0x7ff11d525000
EAL: PCI memory mapped at 0x7ff11d524000
EAL: PCI memory mapped at 0x7ff11d522000
EAL: PCI device 0000:0b:00.0 on NUMA socket -1
EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL: PCI memory mapped at 0x7ff11d521000
EAL: PCI memory mapped at 0x7ff11d520000
EAL: PCI memory mapped at 0x7ff11d51e000
Found 2 usable ports:
Ports 0: 00:0C:29:4C:D9:04 (unknown NIC (PCI ID 15ad:7b0))
Ports 1: 00:0C:29:4C:D9:0E (unknown NIC (PCI ID 15ad:7b0))
[WARNING] You are using a depreciated method for invoking device config. config(...) should be used with named arguments. For details review the file 'device.lua'
could not configure tx queue 0
[ERROR] Lua error in task master
lua/include/device.lua:180: could not configure device 0: error -22
Stack Traceback
===============
(2) Lua global 'errorf' at file 'lua/include/utils.lua:11'
Local variables:
str = string: "could not configure device %d: error %d"
(3) Lua field 'config' at file 'lua/include/device.lua:180'
Local variables:
args = table: 0x41ff56f8 {1:0, 2:1, 3:3, rxQueues:1, rssNQueues:0, speed:0, dropEnable:true, txDescs:256 (more...)}
rss_enabled = number: 0
rc = number: -22
(4) Lua function 'master' at file './examples/quality-of-service-test.lua:38' (best guess)
Local variables:
txPort = number: 0
rxPort = number: 1
bgRate = number: 1500
fgRate = number: 100
txDev = nil
rxDev = nil
(5) global C function 'xpcall'
(6) Lua upvalue 'slave' at file 'lua/include/main.lua:63'
Local variables:
_ = string: "./build/MoonGen"
file = string: "./examples/quality-of-service-test.lua"
devices = table: 0x4001f110 {1:table: 0x40011b50, 2:table: 0x400ada38}
args = table: 0x400a10e8 {1:0, 2:1}
(7) Lua function 'main' at file 'lua/include/main.lua:99' (best guess)
Local variables:
task = string: "master"
lua/include/device.lua:180: could not configure device 0: error -22

CMake settings do not correctly set `g++` as the compiler for C++ files.

I ran into compilation issues with MoonGen when using Scientific Linux 6 and their devtoolset-2 package for gcc, as well as pulling CMake 2.8.8 from this repo.

CMake defaulted to using gcc when compiling C++ files. This lead to a lot of undefined reference errors, as the standard C++ library was not being included.

The fix was to add an explicit SET(CMAKE_CXX_COMPILER "/path/to/g++") in the CMakeLists.txt.

I don't know if this really counts as an issue against the project itself, but more as a troubleshooting thing that might be nice to have in the documentation.

Cheers!

Error encountered using virtual function of 82599

Hi,
I have binded the following two virtual functions of 82599 with dpdk inside a VM
00:05.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed](rev 01)
00:06.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed](rev 01)

They are binded succesfully by ./build.sh script. However when I run the following script:
"./build/MoonGen ./examples/quality-of-service-test.lua 0 1"
I get the error:

[INFO] Found 2 usable devices:
Device 0: 02:09:C0:E8:20:7F (unknown NIC (PCI ID 8086:10ed))
Device 1: 02:09:C0:C4:B1:18 (unknown NIC (PCI ID 8086:10ed))
[FATAL] Lua error in task master
lua/include/device.lua:190: Could not configure device 0: error -22

Stack Traceback

(2) Lua method 'fatal' at file 'lua/include/log.lua:129'
Local variables:
self = table: 0x4117e870 {DEBUG:0, fatal:function: 0x41178138, writeToLog:function: 0x41170280, INFO:1 (more...)}
str = string: "Could not configure device 0: error -22"
(3) Lua field 'config' at file 'lua/include/device.lua:190'
Local variables:
args = table: 0x40b285d0 {rxQueues:1, rssNQueues:0, speed:0, dropEnable:true, txDescs:256, txQueues:3 (more...)}
rss_enabled = number: 0
rc = number: -22
(4) Lua function 'master' at file './examples/quality-of-service-test.lua:40' (best guess)
Local variables:
txPort = number: 0
rxPort = number: 1
bgRate = number: 1500
fgRate = number: 100
txDev = nil
rxDev = nil
(5) global C function 'xpcall'
(6) Lua upvalue 'slave' at file 'lua/include/main.lua:89'
Local variables:
_ = string: "./build/MoonGen"
file = string: "./examples/quality-of-service-test.lua"
devices = table: 0x419409e8 {1:table: 0x41940b30, 2:table: 0x41940ea0}
args = table: 0x41941288 {1:0, 2:1}
(7) Lua function 'main' at file 'lua/include/main.lua:125' (best guess)
Local variables:
task = string: "master"
lua/include/device.lua:190: Could not configure device 0: error -22

Why is that? Can you please comment

Regards
Haris

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.