Vector Packet Processing (VPP) portability on FreeBSD

[Luigi Rizzo]

On Thu, May 13, 2021 at 10:42 AM Francois ten Krooden <ftk at nanoteq.com> wrote:
>
> Hi
>
> Just for info I ran a test using TREX (https://trex-tgn.cisco.com/)
> Where I just sent traffic in one direction through the box running  FreeBSD with VPP using the netmap interfaces.
> These were the results we found before significant packet loss started occuring.
> +-------------+------------------+
> | Packet Size | Throughput (pps) |
> +-------------+------------------+
> |   64 bytes  |   1.008 Mpps     |
> |  128 bytes  |   920.311 kpps   |
> |  256 bytes  |   797.789 kpps   |
> |  512 bytes  |   706.338 kpps   |
> | 1024 bytes  |   621.963 kpps   |
> | 1280 bytes  |   569.140 kpps   |
> | 1440 bytes  |   547.139 kpps   |
> | 1518 bytes  |   524.864 kpps   |
> +-------------+------------------+

Those numbers are way too low for netmap.

I believe you are either using the emulated mode,
or issuing a system call on every single packet.

I am not up to date (Vincenzo may know better) but there used
to be a sysctl variable to control the operating mode:

https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4

SYSCTL VARIABLES AND MODULE PARAMETERS
     Some aspects of the operation of netmap and VALE are controlled through
     sysctl variables on FreeBSD (dev.netmap.*) and module parameters on Linux
     (/sys/module/netmap/parameters/*):

     dev.netmap.admode: 0
     Controls the use of native or emulated adapter mode.

     0 uses the best available option;

     1 forces native mode and fails if not available;

     2 forces emulated hence never fails.

If it still exists, try set it to 1. If the program fails, then
you should figure out why native netmap support is not compiled in.

cheers
luigi