dorfman.eli at gmail.com wrote on Thu, 01 May 2008 16:50 +0300: > InitialR2T=Yes means that R2T is required, hence no unsolicited data. > Only is both sides, initiator and target agree on InitialR2T=No then > first data burst is unsolicited. Thanks for the explanation. I keep getting that backwards. > On Tue, Apr 29, 2008 at 8:05 PM, Pete Wyckoff <pw at osc.edu> wrote: > > But you missed the impact of immediate data. We run with the > > defaults (I think) that say the first write request packet should be > > filled with a bit of the coming data stream. From iscsid.conf: > > > > # To enable immediate data (i.e., the initiator sends unsolicited data > > # with the iSCSI command packet), uncomment the following line: > > # > > # The default is Yes > > node.session.iscsi.ImmediateData = Yes > > > > Looking at the offset printed out by your patch, it is indeed > > non-zero for the first RDMA read. Please correct me if I am > > mistaken about this---you must have tested all four variations of > > with and without the patches on initiator and target side, but I did > > not. > > You are right about the ImmediateData=Yes. > I really missed that, so after all this patch will break current > target implementation and > cause data corruption. > I suggest to postpone this patch till we implement the iSER HELLO > message and then add this patch with the corresponding target patch. > This will allow current initiator to work with current target and new > initiator work with new target. > I still think we should do that since future iser implementation will > probably rely on the spec. We might as well do the Hello message exchange anyway. As Ken points out, the spec would approve. We could even use this opportunity to set the IRD and ORD too, but I'm not sure exactly how that would work in IB once the connection is up. Here we're not proposing a new bit in the Hello message to indicate "VA starts before unsol data", but rather lack of Hello message indicates old initiatior that gets the VA wrong. That will be easy to detect in targets. I wonder if by supporting Hello, that we could remove the use of private data as specified in the IBTA annex? These negotiated parameters (ZBVA and Send w/Inval) could be in the Hello exchange. We still have the need to put VAs in the iSER header to support the non-ZBVA case (pre-ConnectX IB), though. Once we get the Hello worked out, it might be time to update RFC 5046 to encompass this hardware model too. -- Pete |