On Thu, 2010-10-07 at 11:15 +0800, Hillf Danton wrote:
> On Thu, Oct 7, 2010 at 3:38 AM, Robert Love <[email protected]> wrote:
> > On Wed, 2010-10-06 at 12:17 +0800, Hillf Danton wrote:
> >> On Tue, Oct 5, 2010 at 7:16 AM, Robert Love <[email protected]>
> >> wrote:
> >> > On Sun, 2010-09-26 at 07:06 -0700, Hillf Danton wrote:
<snip>
> Thank you for patience and guiding me to right direction, but
> the incremented seq_id is not used by the new fp, as shown by
> the following (in diff format for clear),
>
> static struct fc_seq *fc_seq_start_next_locked(struct fc_seq *sp)
> {
> struct fc_exch *ep = fc_seq_exch(sp);
>
> - sp = fc_seq_alloc(ep, ep->seq_id++);
> + sp = fc_seq_alloc(ep, ++ep->seq_id);
> FC_EXCH_DBG(ep, "f_ctl %6x seq %2x\n",
> ep->f_ctl, sp->id);
> return sp;
> }
>
> and after calling fc_fill_hdr() it seems that the seq_id of
> the new fp still has to be updated, if the incremented has to
> be inserted.
>
Great point. I think that it's pre-incrementing for the next sequence. I
think the variable name should be named "next_seq_id" to make it more
clear.
An interesting fallout of this discussion is that we always reply with
seq_id 0. Unless we send multiple responses, in which case we'd start at
0 and increment by one for each new reply. However, I do not believe
that we ever send more than one response sequence for an exchange. I
think the only time this might happen is if we were to send bursts of
data to a target, but when I looked at fc_fcp_send_data() I don't see
any code doing that.
Here is a snippit from FC-FS-2:
"The Sequence Initiator shall assign a SEQ_ID that is unique between the
Initiator and Recipient Nx_Port pair while the Sequence is open. The
SEQ_ID shall not match the last SEQ_ID transmitted by the Sequence
Initiator for this Exchange for the current Sequence Initiative. ..."
I'm not sure how to satisfy the "unique between the Initiator and
Recipient Nx_Port pair" statement since there is no way of knowing the
list of in-use SEQ_IDs on the other end of the pair. It seems to me that
we could send the response with the (in_fp->seq_id + 1) which would be
better than always sending 0 since "The SEQ_ID shall not match the last
SEQ_ID transmitted by the Sequence Initiator." Right now we would
violate that if the in_fp's SEQ_ID was 0.
Thanks, //Rob
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
