Re: T10 PI offloading seems to be broken in iser/isert in 4.5/4.6-rc

[Sagi Grimberg <sagi-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>]

On 09/04/16 07:58, Christoph Hellwig wrote:
> On Fri, Apr 08, 2016 at 07:36:14PM -0700, Nicholas A. Bellinger wrote:
>> Ah, yes.  However, TARGET_PROT_DIN_INSERT / TARGET_PROT_DOUT_STRIP
>> will only be happening in sbc_set_prot_op_checks() if fabric_prot = true
>> for a backend that does not support PI.
>>
>> Eg: fabric_prot is for the special case where the fabric supports PI,
>> but the backend does not, and the normal feature bits a device would
>> expose for PI are emulated based upon the fabric protection features.
>>
>> Since your backend does support PI, cmd->prot_op should always be
>> TARGET_PROT_*_PASS regardless.
>>
>> The other thing to check is that isert_get_sup_prot_ops() is returning
>> TARGET_PROT_ALL when tpg->tpg_attrib.t10_pi = true.
> Ok, it turns out this problem was a second LUN that doesn't support
> PI.  So the reported bug is for a this fabrics_prot case, the scsi_debug
> LUN was actually doing fine.

OK, good to know.

Since the fabric_prot was added later, I don't think it was properly
tested (and from what I've seen, not a very interesting use-case).

>
> The root cause seems to be that transport_generic_new_cmd allocates
> a prot_sg for all protection cases, which causes isert_reg_sig_mr
> to assign a value to sig_wr.prot even for the strip/insert case,
> which will then cause mlx5 to blow up.  But even when fixing that
> I run into data compare errors, so there's defintively something deeper
> hiding here.

I don't have access to mlx5 devices at the moment so I can't help a lot :(

But data integrity errors sound strange...

Is it possible that the the sess_prot_type is not set correctly?


P.S.
I'm no longer available in @mellanox.com

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html