[Open-FCoE] [PATCH] libfc: Validating SOF, EOF, SEQ_ID, SEQ_CNT, f_ctl for response frames

Joe Eykholt jeykholt at cisco.com
Thu Jul 16 17:22:20 UTC 2009

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,

More information about the devel mailing list