Not familiar with the code.
If it's safe to leave temporarily the epoch without worrying about things changing while we were out of the epoch, then I'm ok.
The other option would be to enter/exit the epoch from within ng_apply_item (conditionally), but it would require to enter/exit the epoch for each data msg.

If there are no objections, I would go ahead and commit this, incorporating the style fixes by @jhb

I see, thanks.

Question: there are three more locations in that source file where NG_SEND_DATA_ONLY() is called and it is not apparent that we are inside NET_EPOCH.
Should we enter NET_EPOCH also there, or we are already in?

Any comments from @erj or @gallatin ?

...or we can also switch to isc_capenable in the same changeset.
The last diff tweaks iflib's ioctl handler to synchronize isc_capenable to if_capenable.

use iri_ifp rather than iflib_get_ifp() in ice and ixgbe.

Note that this patch contains a number of changes that fix separate issues:

1. fix VLAN offload processing handling the case of vtag == 0.
2. use if_getcapenable() rather the isc_capenable because the latter is not synchronized.
3. use iri_ifp rather than iflib_get_ifp() to avoid an additional indirection.

Also fix scctx->isc_capenable and isc_capabilities usage in igc.

Fix the iri_vtag setting logic for all the iflib drivers.

That's right, thanks. The same issue is there for at least em and ixgbe.
I can fix those if you like.

Indeed. I had put the changes to igb in a separate review: https://reviews.freebsd.org/D33156

Use iri_ifp rather than iflib_get_ifp().

Thanks. I think we may get there (getting rid of ifp) at a later step, since some reworking would actually needed within iflib.
This change is meant to simply align em(4) to the other drivers.

Use ri->iri_ifp

Added diff context.

LGTM, thanks

Good idea, thanks! I added just a little comment.

LGTM!

Sounds good. I had not noticed that *if_input returns void.

Merged

Thanks!

LGTM

Good catch, thanks!

Thank you!

Looks good, thanks! However, we should add the same control for the DEV_TAP at line 1860.

Thanks, but the commit looks a bit strange: we are treating the pdev as a bus_dma_tag_t when it's really a pointer to a netmap adapter. It is not used at all on FreeBSD so it doesn't really matter, but maybe I'm missing something.

Usage of "struct device *" was just wrong. Thanks spotting the issue.
Commit 70275a6735df8a514f48be77418491f2f8dba817 should have the same effect.