Page MenuHomeFreeBSD

Fix allocation of queues to CPUs in iflib

Authored by pkelsey on Mar 16 2020, 11:22 PM.



This addresses iflib CPU mapping oddities that were discussed on
the 20190731 iflib call.

Providing sensible defaults for, and giving the user intelligible
control over, the mapping of iflib device queues to CPUs is
complicated by the possible presence/absence of logical cores (in
addition to the physical cores), the possibility that the device
might not be able to know which cores are physical/logical, the
desire to be able to control whether logical cores are used, the
desire to be able to map TX/RX queues to CPUs in (TX,RX) pairs or
not, the desire to support unequal numbers of TX and RX queues,
and the desire to continue to support the ability to experiment
with placing TX queues on logical cores that share L2 with
corresponding RX queues.

This code provides sensible defaults for and gives the user
intelligible control over the mapping of iflib device queues to
CPUs in light of the above, and preserves all existing non-broken
behaviors (such as advancing through available CPUs across
devices when no core_offset is provided). The device sysctls that
govern CPU assignment are now:

iflib.core_offset (existing, CPU ID to begin assigning cores at)
iflib.separate_txrx (existing, whether to pair TX and RX queues on the same core, defaults to 0)
iflib.use_logical_cores (new, whether to try to assign {TX,RX} queue pairs to logical cores that share an L2 cache, defaults to 0)

See the comment on get_cpuid_for_queue() in this patch for all of
the possible behaviors.

This code also ensures that when a reference IRQ is not provided,
TX softirqs are bound to CPUs using the same allocation strategy
that would be used to allocate CPUs to TX IRQs, instead of
leaving it up to the grouptaskqueue code, as is now the case.

(The Intel drivers' practice of providing the corresponding RX IRQ as a reference when creating TX soft IRQs should be looked at, as it's not clear why this is being done, and doing so, whether with the existing iflib code or with this patch, has the effect of asking the grouptaskqueue code to rebind the RX IRQ to a different CPU than it has already been bound to at that point).

Test Plan

Tested on 12-stable and current with igb, ixl, and vmx interfaces, and on systems with and without HT enabled.

Diff Detail

rG FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Has anyone else looked at this yet? I haven't had a chance to.

Concept ACK from me, this looks like a good use of available information to make these tuning decisions. @olivier would you be able to benchmark ix or ixl on server class hardware to check performance changes?

Impact of D24094 "Fix allocation of queues to CPUs in iflib" on FreeBSD 14 current n257351 on forwarding performance:

  • SuperMicro SuperServer 5018A-FTN4 (8 cores Atom C2758 at 2.4GHz)
  • Dual port Intel Intel 82599
  • 5000 flows of smallest UDP packets
  • 2 static routes
  • Traffic load at 14.88 Mpps
  • ICMP redirect disabled
x FreeBSD current n257351, hyperthreading_allowed=off: inet4 packets-per-second forwarded
+ FreeBSD current n257351: inet4 packets-per-second forwarded
* FreeBSD current n257351 with D24094, hyperthreading_allowed=off: inet4 packets-per-second forwarded
% FreeBSD current n257351 with D24094: inet4 packets-per-second forwarded
|+ x+xx+ ++                                       *         * O % %%*%    *|
|   |AM|                                                                   |
|  |__AM__|                                                                |
|                                                     |_______MA________|  |
|                                                              |__A_|      |
    N           Min           Max        Median           Avg        Stddev
x   5       3641766       3666851       3666078     3660317.4     10693.732
+   5       3630515       3691715       3670135     3665515.6     24489.351
No difference proven at 95.0% confidence
*   5       3962488       4120734       4042086       4046775     59963.445
Difference at 95.0% confidence
        386458 +/- 62814.4
        10.558% +/- 1.72196%
        (Student's t, pooled s = 43069.5)
%   5       4041535       4085033       4066412     4063931.8     16453.486
Difference at 95.0% confidence
        403614 +/- 20237
        11.0268% +/- 0.571659%
        (Student's t, pooled s = 13875.8)
This revision is now accepted and ready to land.Mar 14 2021, 7:19 PM