netmap: Invalid argument (22, EINVAL) because ioctl request or ioctl data is not valid

I’m investigating an issue in tcpreplay, but am not sure if that issue might actually be in netmap. See: https://github.com/appneta/tcpreplay/issues/527#issuecomment-438383687.

I’ve got everything running in GDB. My arguments to that function are:

sp->handle.fd


(gdb) print sp->handle.fd
$11 = 3

NIOCREGIF (kinda obvious on that one ;-D)

nmr

(gdb) print nmr
$10 = {nr_name = "enp130s0f0\000\000\000\000\000", nr_version = 13, nr_offset = 0, nr_memsize = 0, nr_tx_slots = 0, nr_rx_slots = 0, nr_tx_rings = 0,
  nr_rx_rings = 0, nr_ringid = 0, nr_cmd = 0, nr_arg1 = 0, nr_arg2 = 0, nr_arg3 = 0, nr_flags = 1, spare2 = {0}}

I’m still reading about what all these things are, but the file handle appears valid. You can see from the source here: https://github.com/appneta/tcpreplay/blob/master/src/common/netmap.c that it is properly set to /dev/netmap. The problem line in questions is 343. That leads me to believe it would have to be a problem with the contents of nmr, but I’m still figuring out what all those fields mean. Am I missing anything a more experienced observer sees?

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 17 (8 by maintainers)

Most upvoted comments

@fklassen Sorry for the inconvenience, but it was necessary to update the ABI.

We actually provide backward compatibility: current applications (pkt-gen, bridge, lb, nmreplay, etc.) are still using the “old” ABI (NIOCREGIF). The new ABI is based on NIOCCTRL and is still not documented. If something broke (when using the old ABI), that was not intentional, and we will investigate that.

vmaffione on Nov 16, 2018

For the sake of completeness I extended the test suite to test the legacy ABI (the one we are all using), with tests on forward and backward compatibility: https://github.com/luigirizzo/netmap/blob/master/utils/ctrl-api-test.c#L186-L287 I don’t see any failure, so I don’t understand what went wrong with your environment. In any case we should be covered now.

vmaffione on Nov 17, 2018

What changed was the (mostly unused) new ABI, and that change was done an a backward incompatible manner: but this was not meant to be an issue, because nobody is using the new ABI yet. Note that the old ABI didn’t change, so applications (that use the old ABI) should not have broken. In any case, the change was needed to fix a mistake; we won’t need to do something like that again.

vmaffione on Nov 16, 2018