I agree with all of the other changes here.

I like the idea, and I don't see anything that looks wrong after looking through it quickly. We've added support to ice(4) internally to allow for an extra interface for traffic mirroring that is attached to the main interface, but we're using the standard iflib device interfaces to create it and manipulate it instead of the pseudo interfaces, so this won't affect that.

It seems like a straightforward enough change to me.

@pkubaj I can just accept it -- it looks good to me.

Any updates? This looks like an ok-enough hack to me. I think my concern when I last looked at this was that this code could change in the future, but I don't think it will; still, it could be safer to avoid changing it directly here.

In D40557#923239, @melifaro wrote:

I guess it deserves some discussion on the interface model part. The alternative fix can be done on the Netlink side (try to avoid calling driver-specific ioctls on the ifarrival event) or by moving ifnet_arrival event later in the chain.
My question is what are the desired ether_ifattach() and ifnet_arrival calls/events semantics. Does the ifnet_arrival event mean "interface is fully ready" so it can be queried/updated for the caller? If not, how can the event listener get notified on the readiness?

This looks accurate to me. Is there other review required from someone in doc?

Bartek is currently out, but I'll approve it in his absence for now. It'd be nice to know why that function is unused.

In D39457#900952, @jhb wrote:

It may be that the current interrupt code has a race in bus_teardown_intr() when used with filters in that we can't ensure that bus_teardown_intr() will block if the filter handler is running on another core, but in that case that's the real race to fix.

Committed in rG35105900c65bb5adcde05d37ae34ad006970d4f9.

In D38929#893145, @jhibbits wrote:

@erj can you fix this the right way given what you also wrote in your now deleted comment? I could just revert the original change to the line if that's all that's needed.

In D38929#886387, @jhibbits wrote:

@erj was the original change to this intended? Before the change it was:

if ((scctx->isc_capenable & IFCAP_RXCSUM) != 0)

From the rest of the file it looks unintended, but I can't tell.

Committed in rG8923de59054358980102ea5acda6c6dd58273957.

In D38376#872298, @pkubaj wrote:

The PR mentions only this one, the others were probably not tested. Do you think it would be appriopriate to add them anyway?

What about everything between I219 (19) and (22)? :p

In D38285#871102, @jhb wrote:

It would be nice to make these dynamically sized rather than a fixed-sized array. However, reviewing and integrating @kib's patch to use the ACPI_DMAR driver for this instead is probably the better long-term fix.

I think this is reasonable.