I'd prefer the check be moved inside _iflib_assert(), but that's just a nit.

What we really care about is not re-ordering the load so that we ensure it happens prior to the loop. So I think you want an atomic with acquire semantics:

"the operation must have completed before any subsequent load or store (by program order) is performed"

To expand on this, the issue is that interrupt handlers are removed via intr_event_execute_handlers() when IH_DEAD is set. The thread removing the intr is woken up, and he calls intr_event_update(). When this happens, the ie_hflags are cleared and re-built from all the remaining handlers sharing the event. When the last IH_NET handler is removed, the IH_NET flag will be cleared from ih_hflags (or ie_hflags may still be being rebuilt in a different context), and the ithread_execute_handlers() may return with ie_hflags missing IH_NET. So we can end up in a scenario where IH_NET was present before calling ithread_execute_handlers, and is not present at its return, meaning we must cache the need for epoch locally.

I like the idea of using a different ether_input() for epoch and non-epoch safe drivers to get the tests out of the critical path. However, this is a minor optimization at best, as branch predictors are really good these days on modern CPUs.

Some feedback:

As we discussed in slack, I'm not a huge fan of fixing things with a callout. If the hardware was amenable, I'd much rather leave the ring partially stocked and drop new packets until we were able to allocate mbufs again. However, based on the findings you reported with igb (it wanting a full rx ring to generate interrupts), I'm afraid that might require too much work from hardware drivers. And I'd prefer a fix to a real problem, even if its not something I personally find appealing, to leaving a real bug unfixed and having machines become unreachable.

Why are there multiple reviews? The other one still appears to be open (https://reviews.freebsd.org/D18856)

There is code which is clearly FreeBSD specific that needs to be converted to comply with style(9).

This fixes GPFs for me when using hwpmc on AMD Rome. The GPFs were triggered out of MSR writes in the amd hwpmc interrupt handler.

This was fixed in r353483, however the wrong differential was tagged in that commit, so this differential was never closed.

Thanks for fixing this. The NULL canaries were left over from when iflib had a separate code path which avoided busdma. When I removed this codepath, I neglected to remove those canaries.

Works fine running on a Netflix cache.

I just looked for a short time.. more comments later..

Yes, I meant adding a KASSERT or at least a comment.

I like this a lot. Note that I only looked at mxge and a few iflib drivers.

Moved PORTREVISION down a line to fix portlint complaint as pointed out by jhb

In my tests of UDP transmit using N copies of netperf on a 14c/28t Xeon E5-2697 v3 (haswell) using a 40Gbe ixl, I see nearly a 100% performance improvement (eg, double the packet rate) as compared to using mp_ring. In fact, for a single-threaded test the packet rate is 4x what it is for mp_ring with tx-abdicate enabled.

Applied suggested changes prior to committing.

In D19111#476197, @hselasky wrote:

@gallatin: Network drivers can also use worker threads instead of IRQ's to process packets. Especially USB network devices.

In D21801#476448, @jhb wrote:

Actually, we need to update the logic that populates the TLS header to stop writing the 8 byte nonce for GCM for 1.3 in ktls_seq? It probably doesn't hurt for it to stay, but it would be cleaner if we removed it. I've actually thought about reworking what we do anyway. The 8 byte nonce doesn't have to be the sequence number, it just has to be unique per record. OpenSSL picks a random 8 byte value and increments it. We could actually do the something similar and generate the TLS header always in ktls_frame(). We would generate an 8 byte random value that is saved in the TLS session when it is created and just increment it for each record that is framed. There's no requirement that the nonce's be monotonically increasing, etc. just unique per record. This would simplify ktls_seq() and would make the 1.3 vs 1.2 handling a bit clearer.

Re-submit diff with -U999999 for full context.

Updated the port to handle TLS 1.3

Applied suggested changes in what I'm about to commit.

• I've taken linimon's changes from bugzilla
• I've hooked the port to the Makefile in the parent

Updated to address feedback from Hans:

• add comment that record_type must be first in the union
• added a constant for the 1.3 GCM iv len and checked it where we check it for 1.2

I tested this, and it performed well and worked fine.

Would it make sense then to assert that the link is down?

I'm not sure, but I think the only way this can happen is when the link is down. Is that the caee here?

Uncrappy is nice. But if we've got lock contention, it would be nice to know why.

In D21122#472928, @olivier wrote:

In D21636#471988, @kbowling wrote:

This isn't worth much consternation but I do wonder if we can try to limit the proliferation of these sockopts. For instance, if you generalize the existing _LB to take a generic integer arg, would that and cpuset achieve the same effect (and generalize to however people want to use those numbered groups?)

• Fixed line wrap issues pointed out by igor

Address bz's concerns:

• Shorten lines in man page
• Make numa_domain consistently uint8_t
• simplify logic in places
• fix some style errors

In D21122#466175, @olivier wrote:

Flamegraph:

• mpring enabled
• mpring disabled