Most of the comments are correct, but the style would be to put the leading '/*' and trailing '*/' on their own lines.

A few other comments in the patch also are not quite correct.

FreeBSD's style is to put ()'s around return values, so:

return (0);

here and elsewhere throughout the patch.

I think it would be simpler to just have two backend structs for tap vs vmnet and then you don't need all the parsing logic for handling '|', etc. Just have a single 'prefix' and use simple 'strncmp' matching without needing all the token, etc. Having an extra struct is pretty cheap in exchange for the code simplicity.

style(9) also does a 4-space continuation indent.

Maybe use strlcpy() instead?

Is this really better than using memcpy() directly? Note that memcpy() in libc on both Linux and FreeBSD will use optimized routines for the current CPU.

Nit: spaces around '+'

Does 'inline' actually make a difference? I recently found in another patch that clang ignored this and made up its own mind to inline or not.

This seems unrelated (separate change) and is also odd style). Can you instead move this code to when the thread is being created as I think that is more common in the existing bhyve source?

Hmm, the name is already set here?

Yes, indeed. Thanks for spotting them.

I knew this was going to come up... Yes, it makes sense.

Thanks, this slipped through during my rebase.

Agreed. This is something actually very old that I still had around.

For sure it doesn't for e1000, so in this case it's useless.

Indeed, this is a leftover of a previous iteration. Thanks.

What do you think about adding this function to the backend API. For netmap, there is no need to copy data into a dummy buffer, we can just move ring pointers.

I think len < 0 must be handled:

if (len < 0) {
   	vq_endchains(vq, 0);
        return;
}

Otherwise, we call vq_relchain(vq, idx, (uint32_t)len); with incorrect parameter and increment used_idx.

Netmap adds TSO flags to the VTNET_S_HOSTCAPS flags, but the latter contain the VIRTIO_NET_F_MRG_RXBUF flag which is not yet supported.

I was able to run this patch only by removing VIRTIO_NET_F_MRG_RXBUF from VTNET_S_HOSTCAPS.

Done. I hope I did not miss anything.

Ok, I thought the rule was not valid for return statements containing a function call.

Good point, but I think it's not convenient in practice, and for two reasons. First, once I implement receive backpressure, discard won't happen anymore (at least that's the plan). Second, making this operation faster would be counter productive, since we are giving less time to the guest to replenish. The result is more packet drops.

You are right. I changed the code so to handle len<=0

Indeed, my original patch had VIRTIO_NET_F_MRG_RXBUF removed. Thanks for spotting.
With the mergeable rx buffers feature on, the guest will indeed fail receiving large packets with small buffers.