Am Freitag, den 15.07.2005, 09:56 -0700 schrieb Dmitry Yusupov:
> On Fri, 2005-07-15 at 11:52 -0400, Ming Zhang wrote:
> > On Fri, 2005-07-15 at 17:43 +0200, Arne Redlich wrote:
> > > it expected to receive in 1 PDU got split into to 2 PDUs because of
> > > the
> > > target using a smaller MaxRxDSL than announced by the ini. Unless I'm
> > > misunderstanding the RFC here, the target isn't required to use the
> > > ini's MaxRxDSL when xmitting, it only must not exceed it. So IMHO, the
> >
> > i agree with this. it is a up bound, not a line have to reach every
> > time.
> >
> >
> > > target's behaviour is alright - except for the handling of MaxRxDSL
> > > during login :P
> > >
> >
> > yes, we need to fix this. we need to add another variable.
> >
> >
> > a simple test will be set the MaxRxDSL in ietd.conf to same or larger
> > value open-iscsi use, and see if there are still corruption.
>
> i'm still not convinced, open-iscsi respects MRDSL <= negotiated.
No doubt about it.
> Once BufferOffset's are in increasing order and no overlays.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But that's exactly what the dumps show. As I've just noticed once more
that different versions of ethereal have problems decoding the traces,
here's a summary:
open-iscsi requests file f19 with 2 Read10 PDUs, one (a) requesting 9k
(a), and one (b) requesting 1k. As IET erroneously believes the MRDSL of
open-iscsi is 8k (clearly IET bug as already stated), it will send the
requested data in 3 PDUs:
#1 8k, offset 0, no F bit, in response to (a)
#2 1k, offset 8k, F bit, in response to (a)
#3 1k, offset 0, F bit, in response to (b)
so at least to me they appear to be in order.
open-iscsi detects the offset of PDU #2 when rx'ing the header, but I
don't see it anywhere taken into account when copying the data from the
rx skb to the scatterlist/scsi buffer.
The linux-iscsi trace (using the same iSCSI params as above on both
sides) shows exactly the same pdu pattern, i.e. f19 is requested with 2
Read10s and tx'd with the above 8k+1k+1k scheme. AFAIK, linux-iscsi
doesn't support out of order data either, but no corruption occurs.
Arne
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
|
