In D51631#1195661, @dsl wrote:

Updated to 0.1.4

Some porters don't mind support (e.g. https://gitlab.fechner.net/mfechner/Gitlab-docu/blob/master/install/16.10-freebsd.md#support-me ). However, we won't know how good these changes are without hands-on experimentation.

The patch works like a charm! This fixes the case I described here (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235556#c2), the stats are now correct: https://www.bsdstore.ru/trash/racct.png
Tested on: FreeBSD 14.0-CURRENT #0 main-n247127-1976e079544-dirty

In D26209#656625, @khng wrote:

In D26209#633596, @c.koehne_beckhoff.com wrote:

• fix compiling

Broken for FreeBSD 13.0-ALPHA2:

--- all_subdir_usr.sbin ---
        uint64_t cpu_maxphysaddr, pci_emul_memresv64;
                                  ^
/usr/jails/src/src_13/src/usr.sbin/bhyve/pci_emul.c:1256:8: error: unused variable 'regs' [-Werror,-Wunused-variable]
        u_int regs[4];
              ^
/usr/jails/src/src_13/src/usr.sbin/bhyve/pci_emul.c:1255:11: error: unused variable 'cpu_maxphysaddr' [-Werror,-Wunused-variable]
        uint64_t cpu_maxphysaddr, pci_emul_memresv64;
                 ^
3 errors generated.

Hi, Checked the vether module for a month under high load ( 13-CURRENT ). I can say that at present this is the only stable way to interact with traffic inside the VALE switch from the host system. if_epair is extremely unstable. It would be very helpful to see the movement of this work.

@novel I checked this patch on my system and it looks good for me.

Probably a good idea to make it tunable and also, it would be nice if the system checks the amount of firmware and noticed message about limit exceed, instead of 'Invalid argument'