Since Netmap applications use regular system calls, like open(), ioctl() and
mmap() to communicate with the Netmap kernel module performing the packet I/O,
the compat_netmap library provides a set of similar APIs to use in place of those system calls,
Since Netmap applications use regular system calls, like open(), ioctl() and
mmap() to communicate with the Netmap kernel module performing the packet I/O,
the compat_netmap library provides a set of similar APIs to use in place of those system calls,
The provided library is currently minimal and doesn't support all the features that Netmap supports,
but is enough to run simple applications, such as the bridge example detailed below.
The provided library is currently minimal and doesn't support all the features that Netmap supports,
but is enough to run simple applications, such as the bridge example detailed below.
there are caveats and limitations to be aware of when trying to use the compat_netmap library, the most important of which are listed below.
Additional caveats are presented in the $RTE_SDK/examples/netmap_compat/README.md file.
These can change as the library is updated:
there are caveats and limitations to be aware of when trying to use the compat_netmap library, the most important of which are listed below.
Additional caveats are presented in the $RTE_SDK/examples/netmap_compat/README.md file.
These can change as the library is updated:
The address, length, flags, offset, and so on arguments are therefore ignored completely.
* rte_netmap_poll() only supports infinite (negative) or zero time outs.
The address, length, flags, offset, and so on arguments are therefore ignored completely.
* rte_netmap_poll() only supports infinite (negative) or zero time outs.
changing the semantics of the usual POSIX defined poll.
* Not all of Netmap's features are supported: "host rings",
changing the semantics of the usual POSIX defined poll.
* Not all of Netmap's features are supported: "host rings",
* The Netmap manual page states that "a device obtained through /dev/netmap also supports the ioctl supported by network devices".
It is not the case with this compatibility layer.
* The Netmap manual page states that "a device obtained through /dev/netmap also supports the ioctl supported by network devices".
It is not the case with this compatibility layer.
-The usual Intel® DPDK initialization code involving rte_eal_init() and rte_eal_pci_probe()
-has to be added to the Netmap application in the same way it is used in all other Intel® DPDK sample applications.
-Please refer to the *Intel® DPDK Programmer's Guide* - Rel 1.4 EAR and example source code for details about initialization.
+The usual DPDK initialization code involving rte_eal_init() and rte_eal_pci_probe()
+has to be added to the Netmap application in the same way it is used in all other DPDK sample applications.
+Please refer to the *DPDK Programmer's Guide* - Rel 1.4 EAR and example source code for details about initialization.
the ported application needs to call initialization functions for the compat_netmap library,
namely rte_netmap_init() and rte_netmap_init_port().
the ported application needs to call initialization functions for the compat_netmap library,
namely rte_netmap_init() and rte_netmap_init_port().
They are definedin $RTE_SDK/examples/netmap_compat/ lib/compat_netmap.h.
The bridge application is an example largely based on the bridge example shipped with the Netmap distribution.
They are definedin $RTE_SDK/examples/netmap_compat/ lib/compat_netmap.h.
The bridge application is an example largely based on the bridge example shipped with the Netmap distribution.
Please refer to $RTE_SDK/examples/netmap_compat/bridge/bridge.c for an example of ported application.
Compiling the "bridge" Sample Application
Please refer to $RTE_SDK/examples/netmap_compat/bridge/bridge.c for an example of ported application.
Compiling the "bridge" Sample Application
If a single -p parameter is given, the interface will send back all the traffic it receives.
If two -p parameters are given, the two interfaces form a bridge,
If a single -p parameter is given, the interface will send back all the traffic it receives.
If two -p parameters are given, the two interfaces form a bridge,
the Environment Abstraction Layer (EAL) options.
Note that unlike a traditional bridge or the l2fwd sample application, no MAC address changes are done on the frames.
the Environment Abstraction Layer (EAL) options.
Note that unlike a traditional bridge or the l2fwd sample application, no MAC address changes are done on the frames.