Chris Leech wrote:
> On Wed, Jul 15, 2009 at 02:40:22PM -0700, Joe Eykholt wrote:
>> Steve Ma wrote:
>>> + atomic_inc(&mp->stats.seq_not_found);
>>> + goto rel;
>>> + }
>>> + sp->cnt++;
>>> + } else if ((sof == FC_SOF_N3) && (eof == FC_EOF_T)) {
>>> + /* last frame in a sequence */
>>> + sp = &ep->seq;
>>> + if ((sp->id != fh->fh_seq_id) ||
>>> + (sp->cnt + 1 != cnt) ||
>> We do see reordering of frames for FCP when interrupt
>> migration moves the receive interrupt to another CPU.
>> So the sequence comparison shouldn't be done unless we somehow
>> figure out how to preserve order in this case.
>
> I was going to argue with you on that. Then I realized that I was
> only thinking about drivers that use napi_schedule(), and that
> reordering is possible for drivers that call netif_rx() directly. And
> I'm only talking about network drivers here, becuase libfc doesn't do
> any receive queuing. It's the intermediate per-cpu backlog queues in the
> netdev layer that can cause problems. So yes, for certain devices irq
> migration can be an issue even though it should be infrequent.
Thanks for the observation, Chris.
fcoe_rcv() can be waiting on the per-cpu receive queue lock,
and when an interrupt migrates another fcoe_rcv() can get the
lock first with a later packet. So the two packets can get on
the queue out of order.
It is infrequent, but observable, and fc_fcp.c handles it correctly,
even when an FCP response comes in slightly before the final data frame.
So, fc_exch.c shouldn't check this.
Thanks again,
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
