Hi Suganath, > Also, Making all PRP buffer may or may not need FW changes (assuming > it is possible.), we may end up into multiple FW version check. I don't understand how submitting an I/O that is guaranteed to honor the constraints of the target NVMe drive could possibly cause problems for the controller firmware. Quite the contrary, it's the best case scenario. > Since this is main IO path and current driver is following H/W > limitation, we should avoid any changes in this area until and unless > change is universal acceptable in FW (for all type of work load). This is why you need to involve the Linux community early in the design process and not when your implementation is complete. We could have told you right away what the correct approach would be for your Linux driver. And that said approach works for products from other vendors so we see no compelling reason to deviate from it. As evidenced by Broadcom disowning the legacy mpt and megaraid drivers, I will be stuck maintaining this mpt3sas code for a decade or more. Long after Broadcom has ended official support and moved on to different ASICs and programming interfaces. Consequently, I am very heavily biased towards solutions that leverage the shared interfaces provided by the kernel and that don't have special cases and workarounds inside the driver. -- Martin K. Petersen Oracle Linux Engineering
