fw_outstanding"(outstanding IOs at firmware level) counter gets screwed up when R1 fastpath
writes are running. Some of the cases which are not handled properly in driver are:
- With R1 fastpath supported, single write from CAM layer can consume 2 MPT frames
at driver/firmware level for fastpath qualification(if fw_outstanding < controller Queue Depth).
Due to this driver has to throttle IOs coming from CAM layer as well as second fastpath
write(of R1 write) against Adapter Queue Depth.
If "fw_outstanding" reaches to adapter queue depth, driver should return IOs from CAM layer with
device busy status.While allocating second MPT frame(corresponding to R1 FP write) also, driver
should ensure fw_outstanding should not exceed adapter QD.
- For R1 fastpath writes completion, driver decrements "fw_oustanding" counter without
really returning MPT frame to free pool. It may cause IOs(with heavy IOs running, consuming whole
adapter Queue Depth) consuming MPT frames reserved for DCMDs(management commands) and
DCMDs(internal and sent by application) not getting MPT frame will start failing.
Below is one test case to hit the issue described above-
- Run heavy IOs (outstanding IOs should hit adapter Queue Depth).
- Run management tool (Broadcom's storcli tool) querying adapter in loop (run command- "storcli64 /c0 show" in loop).
- Management tool's requests would start failing due to non-availability of free MPT frames as all frames would be consumed by IOs.
Fix: Increment/decrement of "fw_outstanding" counter should be in sync with MPT frame get/return.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
Approved by: Ken
MFC after: 3 days
Sponsored by: Broadcom Inc