From what I can see "pf_overload_task()" does not send or receive and IP packets, and does not need to run under EPOCH(9).

Try this:

In D23599#521566, @rscheff_gmx.at wrote:

IPFW/Dummynet appears to now panic with EPOCH assertions (netpfil/ip_dn_*)

Can you upload patch context?

Looks very good. See my two comments.

Looks good to me.

SYSCTL_ADD_NODE() and SYSCTL_NODE() are always MPSAFE.

In D23654#519339, @glebius wrote:

In D23654#519196, @hselasky wrote:

The Mellanox drivers currently manage this internally:
See: https://svnweb.freebsd.org/changeset/base/357294
Usually there are many packets processed per interrupt.

I've seen this change. Was it benchmarked? I'm afraid result might be different to what was before, cause batching inside single call into interrupt handler be definition is a smaller batching than on top of it.

In D23654#519204, @jhb wrote:

I'm not really sure why we need more interrupt types? This seems like it is better named INTR_TYPE_NET_NOEPOCH or something anyway, and if that's the true purpose I think instead we might need to rethink the design of tying the network epoch to the interrupt type? For example, what if instead of teaching ithreads, task queues, etc. about the network epoch directly, we were to have drivers that want to coalesce the epoch do so explicitly in their ISR (this also would let them drop the epoch when doing voluntarily yielding which is one thing np@ asked about on IRC earlier) and either use an alternate if_input or a new if_flags to avoid the recursion in ether_input? I think that approach would be fairly simple while avoiding hardcoding knowledge about the network epoch in various kernel subsystems.

The Mellanox drivers currently manage this internally:
See: https://svnweb.freebsd.org/changeset/base/357294

The LinuxKPI does not depend on Giant. All instances of SYSCTL's in the LinuxKPI can be made MPSAFE.

All sysctls in USB drivers are MPSAFE including uaudio.c .

Rebase patch after r357772.

Don't forget to MFC

@glebius: Looks better now?

I'm good with this change.

Patch looks good.
Do you have a reference for the new PCI ID values?

@jeff: Can you accept this change?

Can the people subscribed to this patch which think the current version is OK accept it again?

Use atomic_load_int() instead of "volatile" as suggested by kib@ .

Exactly what you said, so that the hflags should be constant after MSI(-X) interrupt is set up. So again, I am not sure how did you see leaked epoch entry for mlx5en interrupt thread.

In D23483#516214, @kib wrote:

intr_event_update() is used for all kinds of hardware interrupts.

In which way it is used for MSI ? After registration, since this is the only case where we need to consider changed flags.

In D23408#516172, @glebius wrote:

Since this revision was commandeered, I created a new one: https://reviews.freebsd.org/D23518
I picked up extra driver changes from this one. Thanks, Hans!
I didn't pickup the tick restriction in the cycle. The cycle is finite, I don't see any good reason to limit it unless there is experimental proof of such need. We were talking about limiting to a tick the cycle in the interrupt code. That one is potentially infinite, and there it makes sense. However, with a benchmark first.
I didn't pickup macro renaming. First, it is inconsistent - TASK_INIT2 was renamed, but GTASK_INIT2 was not. Second, the ugly named macro isn't public, so I don't see good reason to rename it. However, I'm not strong in this opinion, I'm open to renaming both TASK_INIT2 and GTASK_INIT2, if more people vote for that.

In D23483#515820, @kib wrote:

In D23483#515809, @hselasky wrote:

In D23483#515796, @kib wrote:

But in fact I still do not understand this patch, or rather, what is the case when it could happen that IH_NET is not seen after ithread_execute_handlers(). We never clear IH_NET, and the _intr_drain() code does not allow to free handler/thread until the thread acknowledges IT_WAIT.

See: intr_event_update()
IH_NET can go away when interrupt handlers are unregistered.

intr_event_update() should not be used at all for MSI threaded handlers, right ? So I do not think it was the cause in the bug you are chasing.
And I think intr_event_update() should park the intr thread for the update to be reliable, but this only matters for shared interrupts ?

In D23483#515796, @kib wrote:

But in fact I still do not understand this patch, or rather, what is the case when it could happen that IH_NET is not seen after ithread_execute_handlers(). We never clear IH_NET, and the _intr_drain() code does not allow to free handler/thread until the thread acknowledges IT_WAIT.

mjg@, mav@, gallatin@: How does the latest patch version look?

Mark ie_hflags volatile to simplify use of atomic.
Make sure ie_hflags is not cleared before update.

@mav:
Can you comment on this change?

jhb@ can you comment if it is safe to access the structure pointed to by "ie" like done in the patch above?

Use atomic_load_int() where appropriate like suggested by mjg@ .

@mjg: Thank you. I'll have a look at this again tomorrow.