On Thu, 2014-03-06 at 17:58 +0200, Sagi Grimberg wrote: > On 2/16/2014 7:38 PM, Sagi Grimberg wrote: > > User may enable T10-PI support per network portal group. any connection > > established on top of it, will be required to serve protected transactions. > > Hey Nic, > > So about this patch I'm not so sure about a couple of things and I would > like to here your comments: > > 1. I added this explicit set because iSER must know about DIF during > connection establishment and not after. > This is because iSER needs to INIT DIF related resources (allocate > signature MRs and signature enabled QP). > > 2. I figured that user should ask for t10_pi support per tpgt if he > exports t10_pi supporting LUNs. > But I'm thinking maybe this should be implicit once user exports a > LUN supporting DIF. Mmmm, good point. > Moreover, the user must *NOT* export DIF supporting LUNs over a > tpgt with active connections that didn't INIT DIF related stuff. > If this happens, we are in a bad situation. Maybe some restrictions > should be done here on exporting LUNs. > So this is where things become problematic.. The issue is that it's assumed at any time LUNs can be added/removed from a given TargetName +TargetPortalGroupTag endpoint, regardless of what type of resources have been previously enabled on a given (active) session. Having to keep track of which LUNs (DIF or non DIF) can be exported on a given endpoint that supports or doesn't support DIF is going to get complicated very quickly. It's also be possible to end up with an asymmetric view of the LUNs, which would be unholy mess to reconcile in configfs. The other issue is how to deal with DIF enabled device available on an traditional iSCSI endpoint that's shared with a DIF enabled iSER endpoint..? > The alternative here is to always INIT DIF extra resources which is > expensive but will resolve the issue as iSER "DIF connections" have no > problem carrying non-DIF transactions. > How expensive per session are we talking..? I'd much prefer to just go ahead and always enable the extra resources at session creation time when the available from the hardware, as it would make life alot simpler wrt to the above.. > 3. Another restriction we talked about in the past was the dependency of > RDMA DIF support in ImmediateData and UnsolDataOuts. > Since iSER must prepare the memory region with DIF (Signature) > attributes using REG_SIG_MR work request *before* doing data > transfer. iSER can't handle data that may or may not come as > happens in ImmediateData and UnsolDataOuts. I can start cracking my > head to try and hack around this issue in SW (really rather not > to...) but at the moment it's just not supported. I think that perhaps > some explicit enforcement need to be made here: DIF=yes ==> > ImmediateData=No, InitialR2T=yes. > > Whats your take on this? > Same issue as above. I think it's most sane to simply implicitly force ImmediateData=No + InitialR2T=Yes when it's detected that the network portal the login was received on is running with DIF resources enabled. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
