Regards,
Quinn Tran
On 4/2/14 11:20 AM, "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote:
>On Wed, 2014-04-02 at 09:51 +0300, Sagi Grimberg wrote:
>> On 4/1/2014 8:45 PM, Nicholas A. Bellinger wrote:
>> > On Tue, 2014-04-01 at 20:27 +0300, sagi grimberg wrote:
>> >> On 4/1/2014 8:09 PM, Martin K. Petersen wrote:
>> >>>>>>>> "Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes:
>> >>> Sagi> I originally wrote the code to support that. But it got left
>> >>> Sagi> behind since I figured it is not an interesting use-case. If
>>your
>> >>> Sagi> beckend doesn't support T10-PI why should the target publish
>>it
>> >>> Sagi> support it and ask the device to strip/insert it? I suppose
>>it is
>> >>> Sagi> to allow the initiator to protect half-way, but I don't know
>>how
>> >>> Sagi> interesting it is if the data is not stored with protection...
>> >>>
>> >>> That depends what you do on the backend. There are several devices
>>out
>> >>> there that expose PI to the host but use a different protection
>>scheme
>> >>> internally. And then synthesize PI on the host-facing side. Some
>>even do
>> >>> T10 PI to an internal protection scheme and then back to T10 PI when
>> >>> talking to the disk drives in the back end.
>> >>>
>> >> Hey Martin,
>> >>
>> >> I understand, but even for internal different T10-PI schemes, is
>> >> stripping protection from incoming data
>> >> at the fabric level (and then do whatever with it in the backend
>>level)
>> >> the right thing to do here?
>> >> I mean we basically lose protection across the PCI with this scheme
>> >> aren't we?
>> >>
>> > The WRITE_STRIP + READ_INSERT case would be still be useful for IBLOCK
>> > backends that don't support real hw PI, so that at least the
>>protection
>> > can be in place for data movement between physical machines.
>> >
>> > Also, I think the amount of changes required to support this type of
>> > configuration in target-core are quite small.
>>
>> So trying to understand how this will come to use.
>> Target will publish the fabric T10-PI support based only on the
>> transport configuration (not accounting the backing devices
>>configuration).
>
>Yes, passing in the transport configuration for PI at
>transport_init_session() time seems to make the most sense here in order
>to address all fabric types.
QT> Ack. Registering PI cap per IT nexus would fit all fabrics.
>
>> Then upon each cmd the target will look on {backstore configuration,
>> PROTECT bit, transport configuration} - then will decide on protection
>> operation (STRIP/INSERT/PASS).
>>
>> Looks right?
>>
>
>Correct.
>
>I'm thinking it makes sense for target-core to perform the WRITE_INSERT
>+ READ_STRIP (in software) when the transport does not directly support
>PI, but the backend has PI enabled.
>
>--nab
QT> I see, this cover the case of a transport within a Portal does support
PI.
>
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
<<attachment: winmail.dat>>
