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
th
Hi Martin,
On Fri, Sep 15, 2017 at 6:37 AM, Martin K. Petersen
wrote:
>
> Suganath,
>
>> Is there any update on the submitted mpt3sas patches.
>
> We are waiting for you to report back your findings on PRP vs. SGL.
We are working on this, since there is h/w dependent, we are in
discussion with H
Suganath,
> Is there any update on the submitted mpt3sas patches.
We are waiting for you to report back your findings on PRP vs. SGL.
--
Martin K. Petersen Oracle Linux Engineering
Hi Martin,
Is there any update on the submitted mpt3sas patches.
Thanks,
Suganath Prabu S
On Fri, Sep 1, 2017 at 2:09 PM, Suganath Prabu Subramani
wrote:
> Hi Martin,
>
> On Fri, Sep 1, 2017 at 8:52 AM, Martin K. Petersen
> wrote:
>>
>> Hi Suganath,
>>
>>> Let me explain - NVME device fast pat
Hi Martin,
On Fri, Sep 1, 2017 at 8:52 AM, Martin K. Petersen
wrote:
>
> Hi Suganath,
>
>> Let me explain - NVME device fast path is possible in two ways. IEEE
>> SGL and PRP SGL. Due to h/w constraint we choose IEEE SGL only for
>> smaller IO size. Both above is true h/w Fast Path and no firmw
Hi Suganath,
> Let me explain - NVME device fast path is possible in two ways. IEEE
> SGL and PRP SGL. Due to h/w constraint we choose IEEE SGL only for
> smaller IO size. Both above is true h/w Fast Path and no firmware
> involvement.
> Agree with you. We are planning to see if we can keep on
Hi Martin,
Replied inline.
Thanks,
Suganath Prabu S
On Thu, Aug 31, 2017 at 8:35 AM, Martin K. Petersen
wrote:
>
> Hi Suganath,
>
>> Theoretically we want to use h/w capability (to translate IEEE to PRP)
>> for smaller IO size to leverage h/w capability.
>
> Nobody says we have to use the capabi
Hi Suganath,
> Theoretically we want to use h/w capability (to translate IEEE to PRP)
> for smaller IO size to leverage h/w capability.
Nobody says we have to use the capability just because the hardware has
it.
Unlike some other operating systems, Linux will only submit I/Os to the
driver that
Hi Martin,
Replied in line.
- I don't understand why you go through all these hoops to decide
whether to use PRPs or IEEE scatterlists. If the firmware translation
is slow, why even bother with the SG format in the first place? Set
the max I/O size to match MDTS and you're done.
=> We wil
Suganath,
> mpt3sas: SGL to PRP Translation for I/Os to NVMe devices
I'm still confused about this patch.
- I don't understand why you go through all these hoops to decide
whether to use PRPs or IEEE scatterlists. If the firmware translation
is slow, why even bother with the SG format
Ventura Series controller are Tri-mode. The controller and
firmware are capable of supporting NVMe devices and
PCIe switches to be connected with the controller. This
patch set adds driver level support for NVMe devices and
PCIe switches.
mpt3sas v4 patset:
1) Removed code which detects gaps/hole
11 matches
Mail list logo
