On 4/28/2015 2:50 AM, Martin K. Petersen wrote:
"Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes:
Sagi> The problem is that the HBA does not have the write_same
Sagi> functionality you introduce here, i.e. generate multiple same
Sagi> protection fields for a single data block.
Adding support to DIX would be problematic since it would essentially
turn a WRITE SAME into a WRITE. You'd only do one block of DMA but you'd
get N blocks going over the wire.
I thought that WRITE_SAME with DIX would include PI for the block that
is being sent over the wire, the initiator and target HBAs will verify
the single block integrity and the target backend will expand the PI
for the number of same sectors involved (unless the target backend
includes another wire, in this case it should handle it like the
initiator...)
In target mode it is conceivable to set up a prot sgl after parsing the
CDB and let the HBA do the work. But I'm not aware of any hardware that
allows that.
I don't either, I think it would be simpler to have the target core
implement it instead of having each fabric driver doing the same thing.
Sagi> In this case, for WRITE_SAME, have the fabrics generate/verify a
Sagi> single data block (one integrity field) like they do today, and
Sagi> then the core will expand it to the correct number of sectors
Sagi> using some form of sbc_dif_expand_same()
Yeah. In a simple world you'd just keep overriding the ref tag in the
received PI tuple. But for performance reasons you'll obviously want to
do I/O in units bigger than a single block. Blindly preallocating PI to
fit the entire I/O is also be problematic, however, since a block count
of 0 unfortunately means "the whole disk".
It seems that the only one that can handle write_same PI expansion is
the backend.
The initiator can pass PI for the block that is transferred, and the
target is responsible to handle it. The target will also pass this
single block with PI to it's backend. The backend is responsible to
update PI for all the sectors that are written.
Sounds right?
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
