Re: [PATCH 07/16] nvme-rdma: Add metadata/T10-PI support

[James Smart <james.smart@broadcom.com>]

On 1/23/2020 7:34 AM, James Smart wrote:
>
>
> On 1/23/2020 1:59 AM, Max Gurtovoy wrote:
>>
>> On 1/22/2020 11:57 PM, James Smart wrote:
>>> On a per-io basis, there needs to be specific descriptions of the 
>>> DIF information to program the port hardware.  Things such as block 
>>> size, type, and so. I see this routine using a mix of the bio that 
>>> is associated with the original request as well as the namespace 
>>> pointer to get this info.    To me the reaching into the bio, as 
>>> well as the locating of the ns structures are reaching into the 
>>> other layers too much.
>>>
>>> Wouldn't we be better off with with the core layer doing all the 
>>> reaching and setting up a pi structure in the nvme_request with this 
>>> information ?   replace has_pi with this pi struct and 
>>> "nvme_req(rq)->pi.pi_type == 0" is equivalent to has_pi ? If we 
>>> didn't want to replicate the PI info, then nvme_request can simply 
>>> add a pointer to the ns, and the ns can be looked at explicitly to 
>>> gather the attributes.
>>>
>>> Thoughts ?
>>>
>> NVMe namespace is used by RDMA/TCP/FC transport drivers in each 
>> queue_rq implementation. We can pass it instead of reaching it from 
>> the rq, if this looks better.
>
> ?? there hasn't been any reason to look at the namespace by the 
> transports to date.
>
> But yes, I much prefer passing the ns and using it for the dif info.  
> This removes what I didn't like - encoding the relationship of how to 
> get from the rq to ns in each transport.
>

also means the bio isn't necessary in most of the other routines until 
you call blk_rq_count_integrity_sg().  blksz can come from (1 << 
ns->lba_shift)

-- james


_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme