On 10/12/10 12:10 PM, Robert Love wrote:
> 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.
Yes. I don't think the change is necessary.
> 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. ..."
Maybe they mean the ordered pair (initiator, recipient) where
(recipient, initiator) is a different pair. I'm not sure but that
seems reasonable to me. Also, note this applies "while the sequence
is open". I understand the sequence to be closed after the last frame has
been sent or received, so as soon as we receive an ELS request, say,
from a remote port, that sequence is closed.
We don't just want to take the incoming sequence and just increment it,
since that may be a sequence number being used on another CPU between
the same initiator-recipient pair. In order to handle the case where
firmware (for fnic) simultaneously generating long-lived data sequences,
we should avoid overlapping the sequence-ID range with the firmware's
range. One solution is to have a base sequence-ID that is used by
libfc, and add in the CPU number (assuming not too many CPUs), assuming
that the sequence will be a single frame or sent in order before other
sequences from the same CPU.
> 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.
I'd have to research this more. Perhaps it is referring to a certain
situation that doesn't come up. I don't have time to dig into the
document right now.
This is a good thing to figure out so we get libfc correct for everyone.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
