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

How to dump a panic when the kernel crash during boot before loading disk controller drivers ?
Can I compile a kernel with .debug embedded into the kernel ?

New tests output following r325872 that fixed cbc key lenght:

Updating test scripts following kristof's advices

Once I've applied this patch on my system (that is already patched with D11727 and D13096) it panic.

In D11727#272295, @shurd wrote:

Created D13096 to fix the overallocation of queues. However, even with 24 queues, there should have been two per core (one per thread with HTT), not one per core across the two sockets.

I don't reach to apply the patch, and when I've tried to "manually" merge it, I've broke the compilation :-(

In D11727#271873, @krzysztof.galazka_intel.com wrote:

Are you sure about the number of queues? For iflib version of driver the default number is based on number of cores. Are you setting dev.ix.X.override_n(r|t)xqs sysctls?

In D11727#271859, @shurd wrote:

In D11727#271776, @olivier wrote:

Second, on a Dual CPU, Xeon_E5-2650 (12Cores), with Intel 82599ES 10Gigabit (using default 8 queues):

Hrm... is that two E5-2651s for 24 cores total, or two 6-core E5s for 12 cores total?

In D11727#271847, @sbruno wrote:

@olivier Can you post the sysctl/loader.conf settings you are using from both iterations of the test?

In D11727#271845, @sbruno wrote:

@olivier So a decrease of ~33% with IFLIB?

Here are my updated benches "forwarding smallest packet size" results on 2 different hardware.
I'm using a fresh head (r325763) and the latest diff (35190) of this review.