Yes, I confirm a little improvement on small devices (same iflib.tx_abdicate=1 and ip_redirect disabled).

I've forgot to disable IP redirect in my previous bench.
Here are the other results, on 3 different small platforms (-5% on all).
All of these are using common tuning features for routing/firewalling which are:

• net.inet.ip.redirect=0 and net.inet6.ip6.redirect=0, this allow to re-enable fastforwarding path
• dev.igb|ix.X.iflib.tx_abdicate=1, because they are receiving maximum link packet rate

Here is the first result on forwarding performance impact on low-end hardware (AMD GX-412TC, 4Cores Intel i210AT) :

In D15789#334385, @bz wrote:

I am totally not surprised by these numbers. However (a) did you do the same test for IPv6? (b) is that a forwarding setup or an end node setup? (c) how many route updates per second did you try on a forwarding node?

On a 2 sockets, 12 Core Xeon E5 2650 with a Mellanox ConnectX-4:

Same improvement on 8-cores ATOM with ixgbe drivers:

Lot's better on 4core AMD, but need to reset my non-IPMI Netgate tomorrow on the lab:

Panic on PC engines APU2 (AMD GX-412TC):

Then, here is my bench results regarding forwarding performance impact with this patch: I'm using a simple 802.1q setup (no LAGG).
Configuration on the Device Under Test (DUT):

In D14385#301730, @ae wrote:

Reducing inbound call path improves forwarding performance for up to 20%. Additional entries can hit performance. This is not noticeable for stock FreeBSD, that can't do more that 3-5Mpps due to lock contention. But when packet rate is about 10-12Mpps it will be significant. We can ask Olivier to try test with our patches.

OK: This patch improves ixgbe performance with 8core Xeon, but on a 4core Atom with igb, I've got a big degradation (almost half performance):

Any news about pushing this change to head ?

ConcurrencyKit was MFC : https://svnweb.freebsd.org/base?view=revision&revision=328515

And what about updating all ports depending of your renamed ports ? like devel/pear-PHP_CodeCoverage

Yes it's work now, and here are the result: This patch greatly improve D11727 performance!

In D9876#280057, @avg wrote:

Is there still an interest in getting this moving forward?
I think that it should be relatively easy to address my comments and get this into a committable shape.

Same problem on fresh r326378 "panic: Lock (rw) ifnet_rw not locked ".
I can fix this problem by adding kern.smp.disabled="1" into the boot/loader.

Still the same problem: I've svnuped to r326359 and I've still have this panic (only when this patch is applied):

Would it be possible to get the output of the ddb "ps", "show all locks", and "show witness" commands? This is just weird.

I've got a new panic (head with WITNESS and INVARIANTS enabled):

In D13167#274313, @pizzamig wrote:

This PR can be merged in quarterly.

Do you think I can add:

MFH: 2017Q4

in the comment?

In D12446#274285, @shurd wrote:

And you try this after r326033? These issues could have been caused by the memory corruption fixed in that commit.

In D12446#273195, @shurd wrote:

Hrm... you could build a kernel without ix in it and kldload if_ix after the system is up... though that may cause the issue to not occur.

Good catch for the no_dad!

Add no_dad to inet6 setup for avoiding a sleep