Variables sometimes not passed to task slave functions correctly

[NetronomeMoongen]

Pulled the latest version of MoonGen on 4 April 2017 and successfully built it on Ubuntu 16.04.1 machine running kernel 4.4

Bound devices to igb_uio

Used the packetgen.lua script in examples/netronome-packetgen to transmit packets with a src mac of fa:16:3e:7e:13:78.

The value from the command line is correctly read and converted to a MAC address, but somehow gets corrupted when passed to the tx slave function via libmoon startTask function:

Code used to call / kick off the tx slave to handle packet creation and transmission:

print(string.format("Src MAC before starting task: %x\n", clParams.srcMacBase)) libmoon.startTask("txSlave", devices[i], portId, slaveId, clParams)

The value of the src mac printed here is correct)

Code for tx slave (short snippet of first part of tx slave):

function txSlave(device, portId, slaveId, clParams) print(string.format("Launching TX slave: %u, Core: %u, Port: %u", slaveId, mg:getCore(), portId)) print(string.format("Src MAC in TX slave: %x\n", clParams.srcMacBase))

At this point, it prints out a wrong src mac of fa:16:3e:7e:13:74

Somehow the value got corrupted between startTask call and the txSlave function.

Command line for packetgen.lua:

cws: MoonGen/examples/netronome-packetgen

../../build/MoonGen packetgen.lua --src-mac fa:16:3e:7e:13:78 -s 1 -tx 0 -rx 1 --timeout 20

It uses 2 interfaces bound to igb_uio, and the dpdk-conf.lua script in libmoon is adapted to put those two devices in the pciWhitelist

[NetronomeMoongen]

This does not always happen. For example, setting the src MAC to 01:02:03:04:05:06 does not seem to have this issue

[emmericp]

Yeah, the argument passing code is somewhat messed up, also mac addresses are somewhat messed up.

The problem seems to be here that we have two representations of MAC addresses internally, one as a double (48 bits is fine) and one as a struct that is used internally. I'll have a look at this issue next week.

[emmericp]

okay, I managed to reproduce this and it's a different (but similar) issue than I thought. I've fixed it in libmoon here: https://github.com/libmoon/libmoon/commit/08255c3345590edd0be4490842a03a9c9d389dfd

I'll update the dependency/submodule in MoonGen tomorrow together with a few other fixes.