Hi Everyone - Broadcom RAID controller division has designed and manufactured the next generation high performance storage I/O and RAID controllers which are significantly different from existing IT HBA controller and MegaRAID controller and they are architected with significant redesign from the previous generation of controllers to meet performance needs + simplified Raid IO path for driver and OS stack (all complex part of RAID is now handled by h/w in new architecture ). Broadcom currently has Fusion-MPT (Fusion Message Passing Technology) based I/O controllers (IT/IR HBA) primarily managed by mptsas,mpt3sas drivers based on MPT generations and MegaRAID product family of RAID controllers primarily managed by megaraid_sas driver, The MegaRAID controllers are based on a mix of MPI and MFI interfaces. IT/IR HBA and MegaRAID firmware are tightly coupled in some cases but use proprietary interfaces while interacting with the drivers. In the past, these two product lines were developed in parallel and hence diverged into two different user interfaces and different IO path stack. The existing products are compliant with one of the MPI versions from 1.0, 2.0, 2.5 and 2.6. There were certain challenges in MegaRAID controller product architecture which made it difficult to extend to its next generation of product. Broadcom decided to re-architect hardware and firmware's components completely to overcome the extendibility issues of existing controllers and derived a new interface specification named MPI3.0 and transport technology named MPI3.0. Original idea of this new design is to extend performance and functional requirements to the next level as current design has already saturated this goal. Even though the name of this new interface is MPI revision 3.0, it is a significant lift from the current MPI2.6. I will cover some of the key differences in next session. Broadcom has evaluated thoroughly on the merits and drawbacks of managing the new controllers based on MPI3.0 using existing drivers vs a brand new driver and decided to develop a new driver called <mpi3mr> to manage it's MPI3.0 generation of controllers onwards for next decade. A key feature of this new driver is to deliver a single, unified driver that covers both our tri-mode HBA and RAID Controller families. This simplification is an important aspect of Broadcom's next generation tri-mode controllers to achieve unified software stack and to enhance overall performance of the controller. Hence, we are looking towards submitting a brand new driver for the Broadcom new generation unified tri-mode HBA and RAID controllers. This Introduction is submitted as a heads-up prior to submitting the driver patches and soliciting feedback for the new driver submission. New driver named - <mpi3mr> driver will manage both HBA and RAID mode of new controller products and it is a unified driver playing the role of megaraid_sas and mpt3sas driver for future generation of Broadcom's RAID/HBA controllers. Broadcom believes that the key advantages of a new driver to manage the next generation storage controllers are - - Unified host interface for both RAID and HBA modes of the controller - Heavy automated I/O handling at the hardware level to enhance the performance and to have thin driver stack - Exposes dedicated Admin queue and IO queue pairs. - Different system interface registers exposed to bring up, reset and shutdown the controller similar to NVMe. - Improved memory requirement constraints. For example - No constraint of the same 4GB memory region requirement for request frame pool. The controller can support segmented request frame pool etc. - Firmware Diagnostic buffer interface is redesigned. - No requirement of Fast Path and LDIO path in driver (primarily all megaraid_sas_fp.c code is no more required) - Multiple IO submission and completion queue concept. - Does not use the doorbell mechanism for handshake with FW prior to interrupt setup. All management communication will happen through dedicated Admin Queue. - IOCTL interface is not similar to the older generation of controllers. - No difference between SGE vs PRP creation of NVME drives. It is all IEEE SGE. - There is no significant logic change in the driver for handling bare drives and volumes and those are encapsulated in the hardware/firmware level. - Because of the new h/w interface (admin, submission queues), memory allocation requirements are significantly changed. We will be submitting PATCH/RFC soon for upstream review. Thanks, Kashyap
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
