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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
