LSI - MR-Fusion controller driver <mrsas> patch and man page

[Desai, Kashyap]

> -----Original Message-----
> From: Doug Ambrisko [mailto:ambrisko at cisco.com]
> Sent: Friday, December 06, 2013 9:52 PM
> To: Desai, Kashyap
> Cc: freebsd-scsi at freebsd.org; scottl at netflix.com; sean_bruno at yahoo.com;
> dwhite at ixsystems.com; jpaetzel at freebsd.org; Maloy, Joe; Mankani,
> Krishnaraddi; McConnell, Stephen; Saxena, Sumit; Radford, Adam; Kenneth
> D. Merry
> Subject: Re: LSI - MR-Fusion controller driver <mrsas> patch and man page
> 
> Sounds like good progress.  I'll need to play with it a bit.  One question I have
> with fast path, is how does LSI determine if they should use that method
> versus the RAID firmware?  The problem I've seen with fast path is that it
> skips the NVRAM cache which is a huge performance boost for us.  Is there a
> sysctl to control it? 

Fast Path will not be enabled for Cached VDs. Driver choose Fast Path provided information from firmware.
You can find out those bits (fpCapable) in Raid Map.

>  I could probably read through the code to figure it out but
> thought it would be good to get an idea of how LSI plans to use it since you
> guys are the experts on this feature.  I understand from Adam that LSI uses
> this to increase the IOPS.  I can see it potentially used if an SSD is in the
> system so then LD or PD access could be improved to that type of device.  In
> past experience fast path was slower and created a bunch of SCSI sense
> errors reported by the RAID firmware.  That is one reason why I removed
> support of fastpath in mfi.  I also didn't want to introduce potential bugs if
> the RAID firmware and driver got out of sync. due to bugs.  Recently we
> found with SW RAID that trying to load balance IOs across drives can defeat
> read ahead caches of disks.


LSI have never heard anything like above in <megaraid_sas> linux Driver or any other OS driver for MR controllers.
If there is really such a case, we can correct it or provide user option to bypass load balancing, but as I mentioned, we have never hear anything like that from customer.

Thanks, Kashyap

> 
> Thanks,
> 
> Doug A.
> 
> On Fri, Dec 06, 2013 at 02:37:21PM +0000, Desai, Kashyap wrote:
> | Hi,
> |
> | Please consider attached patch for FreeBSD upstream check-in.
> |
> | Please find attached patch for <mrsas> driver for LSI's MegaRaid
> Controllers. This driver supports Thunderbolt onwards Device IDs of MR
> controllers.
> | Currently it supports 0x005B and 0x005D Device IDs.
> |
> | NOTE : This driver will not eliminate or by pass any functionality of <mfi>
> driver which already support above to Device IDs to keep existing user
> experience unchanged.
> |
> | <mfi> Driver will be always given priority over <mrsas> driver and
> | only if customer/user wants to use/migrate from <mfi> to <mrsas>, it
> | will hook up into kernel via device.hint rules. (Attached is mrsas man
> | page for more info.)
> |
> | LSI will continue to update <mrsas> driver in future in timely bases.
> | We have another set of patch in pipeline to be submitted for <mrsas>,
> | but need first go ahead for attached patch and later we will continue
> | to keep <mrsas> up-to-date (In sync with LSI released driver which is
> | available at lsi's external site)
> |
> | Apply patch with "patch -p0 < patchname.patch" from head directory.
> |
> | -- Few notes for user--
> | LSI recommends using fusion_force bit In hint settings at start of the day, if
> they want to use <mrsas>. ( <mfi> will be a default choice for MR-Fusion
> HBA), if will be changed only with fusion_force hint settings. (See mrsas man
> page) Changing any default behavior is well tested for most of the condition.
> | Switching from <mfi> to <mrsas> for MR-Fusion options is designed to
> allow user as one time choice, though multiple time switch from <mfi> to
> <mrsas> is possible, it is not recommended. So, user needs to decide from
> start of the day, which driver they want to use for MR-Fusion  card.
> |
> | -- Implementation details --
> | To support this feature, we have modify <mfi> code to change default
> return type from probe. Currently <mfi> driver return
> "BUS_PROBE_DEFAULT". <mfi> driver has been be changed to return
> "BUS_PROBE_LOW_PRIORITY" if fusion_force hint from device.hints  is set.
> | Please notice, above mentioned implementation in <mfi> driver is only
> applicable in case of  MR-Fusion controller detection. For any other
> controllers, supported by <mfi> driver, the behavior of probe return will
> remain same as before.
> |
> |
> | -- High level feature list of <mrsas> -- 1. Supports Fast Path feature
> | of LSI controllers.
> | 2. Supports 4K sector Drives.
> | 3. CAM layer based interface. All VDs will be attached to CAM layer
> | (Expected storage will be visible in "camcontroll") 4. Complete
> | support of Online Controller Reset. (OCR) 5.  OCR on Fimrware fault and IO
> timeout case.
> | 6. Work well with <storcli> management application which is generic
> application provided by LSI for all other Operating system.
> | 7. Supporst DIF enabled VDs (Same support as provided in Linux and
> | other OSes in FreeBSD) 8. Fast Path Load balance support.
> |
> | - In summary, this driver is in part with Linux based MR drivers and
> | all other features will be available to <mrsas> as planned activity
> | from LSI
> |
> | This code is well tested by LSI Q/A team on 32 bit and 64 bit FreeBSD
> Released OSes.
> |
> |
> | Thanks, Kashyap
> |
> 
> 
>