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.
> BTW, the only non-FCP sequences that we handle as multiple frames
> are CT GPN_FT responses. fc_disc.c already checks that they
> arrive in order, so we really don't need to check it here.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
