On 3/11/2014 1:26 AM, Nicholas A. Bellinger wrote:
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.
I'm not so sure. maybe I'm not seeing the bigger picture here, but when
exporting a backstore
you can check:
if (device->dif_support == tpgt->dif_support)
go ahead and export
else
fail
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..?
This is why we need to restrict it. I don't think this is a healthy
situation.
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..
It's pretty substantial. we are holding x3 MRs than before and the QP is
usually bigger (although
in the isert case it is the same size). So the resources grow with
sessions * num_cmds_per_session.
The problem is that it's seem so so redundant for cases that don't care
about DIF. We will end up
allocating and carrying pools that we will never touch.
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.
So you think Implicit is better than explicit. OK.
So I didn't find a hook to do that. Any hints you can give me?
Sagi.
--
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
