>>>>> "Sagi" == Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> writes: Sagi, Sagi> I see, It's just confusing to see flags such as Sagi> REF_INCREMENT/GUARD_CHECK/REF_CHECK associated with a set of prot Sagi> operations, but I guess it's just me. Do you really need the mask Sagi> anyway? seems like just an extra precaution against wrong Sagi> flagging. I did it this way to avoid having several additional special cases in the hot path. Instead I apply a mask at the end to filter out any flags that would be invalid for that particular protection operation. It simplified the protection prep code significantly. I was also afraid of drivers blindly using the flags to fill out IOCB fields. I was guilty of that myself in the ones I converted and it tripped firmware errors in several cases during qualification runs. So I decided to be on the defensive side about the flags I send down to the LLD. I'd also rather have that filtering encapsulated in single location instead of every driver having to figure out whether it's being presented with a valid combination of flags or not. Sagi> Nice, I posted "RDMA signature feature update" preparing iSER DIF Sagi> code to complement this change - all that is left now is a Sagi> straight-forward conversion. Great! -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
