Page MenuHomeFreeBSD

if_epair: fix race condition on multi-core systems

Authored by grembo on Mar 15 2022, 5:48 PM.
Referenced Files
Unknown Object (File)
Wed, Jul 10, 6:26 PM
Unknown Object (File)
Thu, Jul 4, 1:42 PM
Unknown Object (File)
Fri, Jun 28, 7:22 PM
Unknown Object (File)
Jun 3 2024, 6:44 PM
Unknown Object (File)
Jun 1 2024, 5:35 PM
Unknown Object (File)
May 24 2024, 2:12 AM
Unknown Object (File)
Jan 12 2024, 9:31 AM
Unknown Object (File)
Dec 22 2023, 3:59 AM



As an unwanted side effect of the performance improvements in
24f0bfbad57b9, epair interfaces stop forwarding traffic on higher
load levels when running on multi-core systems.

This happens due to a race condition in the logic that decides when to
place work in the task queue(s) responsible for processing the content
of ring buffers.

In order to fix this, a field named state is added to the epair_queue
structure. This field is used by the affected functions to signal each
other that something happened in the underlying ring buffers that might
require work to be scheduled in task queue(s), replacing the existing
logic, which relies on checking if ring buffers are empty or not.

epair_menq() does:
  - queue mbuf
  - if testandset BIT_QUEUE_TASK:
      enqueue task

epair_tx_start_deferred() does:
  - swap ring buffers
  - process mbufs
  - clear BIT_QUEUE_TASK
  - if testandclear BIT_MBUF_QUEUED
      enqueue task

As 13.1-PRERELEASE is affected, MFCing is imperative.

PR: 262571
Reported by: Johan Hendriks <>
MFC after: 3 days

Test Plan

Diff Detail

rG FreeBSD src repository
Lint Not Applicable
Tests Not Applicable

Event Timeline

This looks good to me. I'll give bz@ another day to comment and then I'll commit.

I've run my previous benchmarks, and I'm not seeing major performance effects of this patch.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 16 2022, 11:30 PM
This revision was automatically updated to reflect the committed changes.