364fe8e597
writes are running. Some of the cases which are not handled properly in driver are: 1. 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. 2. 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- 1. Run heavy IOs (outstanding IOs should hit adapter Queue Depth). 2. Run management tool (Broadcom's storcli tool) querying adapter in loop (run command- "storcli64 /c0 show" in loop). 3. 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 |
||
|---|---|---|
| .. | ||
| mrsas_cam.c | ||
| mrsas_fp.c | ||
| mrsas_ioctl.c | ||
| mrsas_ioctl.h | ||
| mrsas_linux.c | ||
| mrsas.c | ||
| mrsas.h | ||