Page MenuHomeFreeBSD

mpi3mr: Implement reply queue watermark check to throttle IO submission
AcceptedPublic

Authored by chandrakanth.patil_broadcom.com on Sun, Oct 4, 11:50 AM.
Tags
None
Referenced Files
F174894139: D60296.diff
Tue, Oct 6, 7:53 PM
F174851536: D60296.diff
Tue, Oct 6, 12:57 PM
Unknown Object (File)
Mon, Oct 5, 3:46 AM
Subscribers
None

Details

Summary

On certain Broadcom MPI-3 controllers (such as the SAS5116 family),
under heavy workloads, operational reply queues can experience severe
congestion. If an operational reply queue fills up completely, the
hardware controller cannot post completion descriptors, resulting in
missed completions, I/O timeouts, and fatal controller lockups.

To prevent this condition, firmware advertises whether the controller
requires a request limit per reply queue via the
MPI3_IOCFACTS_FLAGS_MAX_REQ_PER_REPLY_QUEUE_LIMIT flag in IOCFacts.

Implement a driver-level throttling workaround when this flag is set:

  1. Calculate a congestion watermark for each operational reply queue (num_replies - (MPI3MR_THRESHOLD_REPLY_COUNT * 2)).
  1. In mpi3mr_submit_io(), check the number of pending I/Os against the reply queue watermark. If the queue is nearing capacity, push back I/O submission by returning EAGAIN, allowing CAM to set CAM_RESRC_UNAVAIL and requeue the CCB until in-flight completions drain.
  1. Expose the dev.mpi3mr.X.reply_qfull_count sysctl so administrators and developers can monitor queue throttling events.
Test Plan
  • Clean build with WERROR=-Werror across FreeBSD 16, 15, and 14 with INVARIANTS/WITNESS enabled; git bisect verified.
  • Stress tested with high queue depth I/O (fio) on SAS5116 to saturate operational reply queues.
  • Confirmed that I/Os are throttled via CAM_RESRC_UNAVAIL, dev.mpi3mr.X.reply_qfull_count increments under congestion, and the controller avoids reply queue overflow lockups.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped