Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Dec 2013 05:50:35 +0000
From:      "Desai, Kashyap" <>
To:        Doug Ambrisko <>
Cc:        "" <>, "Radford, Adam" <>, "Kenneth D. Merry" <>, "" <>, "Mankani, Krishnaraddi" <>, "" <>, "Maloy, Joe" <>, "" <>, "" <>, "McConnell, Stephen" <>
Subject:   RE: LSI - MR-Fusion controller driver <mrsas> patch and man page
Message-ID:  <>
In-Reply-To: <>
References:  <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

> -----Original Message-----
> From: Doug Ambrisko []
> Sent: Friday, December 06, 2013 9:52 PM
> To: Desai, Kashyap
> Cc:;;;
>;; 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 questio=
n 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 i=
> skips the NVRAM cache which is a huge performance boost for us.  Is there=
> sysctl to control it?=20

Fast Path will not be enabled for Cached VDs. Driver choose Fast Path provi=
ded 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 =
> guys are the experts on this feature.  I understand from Adam that LSI us=
> this to increase the IOPS.  I can see it potentially used if an SSD is in=
> system so then LD or PD access could be improved to that type of device. =
> 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 bu=
gs 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 defe=
> 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 lik=
e 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 <=
> 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=
> page) Changing any default behavior is well tested for most of the condit=
> | 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=
> 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
> |

Want to link to this message? Use this URL: <>