[Open-FCoE] [RFC PATCH 1/6] libfc: Fix the RPORT state machine which was preventing VN2VN connection setup.

Robert Love robert.w.love at intel.com
Sat Jan 22 01:25:16 UTC 2011


On Fri, 2011-01-21 at 16:46 -0800, Robert Love wrote:
> On Thu, 2010-10-28 at 17:15 -0700, Joe Eykholt wrote:
> > 
> > On 10/28/10 11:48 AM, Kiran Patil wrote:
> > > From: Kiran Patil <kiran.patil at intel.com>
> > > 
> > > Problem: VN2VN connection setup between initiator and target is failing because both
> > >         side (initiator and target) failed to respond to FLOGI.
> > > 
> > > Reason: If RPORT is in state INIT and receives FLOGI request,
> > >         function fc_rport.c:fc_rport_recv_flogi_req rejects
> > >         FIP (FLOGI) request, hence VN2VN (point to point) connection setup fails.
> > > 
> > > Fix:    It is normal and expected the state of RPORT (which are created after discovery)
> > >         to be INIT. Allow RPORT state machine to continue and accept FLOGI requests
> > >         instead of rejecting it.
> > > 
> > > Technical Details: N/A
> > > 
> > > Signed-off-by: Kiran Patil <kiran.patil at intel.com>
> > > ---
> > > 
> > >  drivers/scsi/libfc/fc_rport.c |    7 ++++++-
> > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c
> > > index ed84b59..b04f939 100644
> > > --- a/drivers/scsi/libfc/fc_rport.c
> > > +++ b/drivers/scsi/libfc/fc_rport.c
> > > @@ -787,12 +787,17 @@ static void fc_rport_recv_flogi_req(struct fc_lport *lport,
> > >  		     fc_rport_state(rdata));
> > >  
> > >  	switch (rdata->rp_state) {
> > > -	case RPORT_ST_INIT:
> > >  	case RPORT_ST_DELETE:
> > >  		mutex_unlock(&rdata->rp_mutex);
> > >  		rjt_data.reason = ELS_RJT_FIP;
> > >  		rjt_data.explan = ELS_EXPL_NOT_NEIGHBOR;
> > >  		goto reject;
> > > +	/* 
> > > +	 * Moved RPORT_ST_INIT case here, to allow RPORT state machine to
> > > +	 * continue instead of rejecting the FIP if state of RPORT is INIT
> > > +	 * (which is normal)
> > > +	 */
> > > +	case RPORT_ST_INIT:
> > 
> > I think it was correct before.  If FIP is really ready, the rport should
> > be in FLOGI state.  Otherwise we might accept a FLOGI before FIP is ready.
> > FIP calls rport_login() once it has received a beacon from the rport.
> > Until then, it isn't supposed to accept FLOGIs.
> > 
> 
> Joe, is there a reason that we wait for a beacon before sending a FLOGI
> to an rport?
> 
> From fcoe_ctlr_vn_disc:
> 
> if (frport->time)
> 	lport->tt.rport_login(rdata);
> 
> Where frport->time is only incremented from 0 when we receive a beacon.
> 
> From what I can find in the various documents/presentations after we
> claim the LUID we should wait ANNOUNCE_WAIT, so that we can collect
> claim responses) and then go to operational mode. To me, operational
> mode means that we can send a FLOGI.
> 
> We create new fcoe_rports when we either receive claim replies or claim
> notifications. So, there's nothing else to wait for. We've claimed our
> LUID and we know the other rports exist, because they notified us of
> their existence. Why wait to login?
> 

I think I understand now. The beacon is an indication that the entity is
in operational mode and can be logged into; claim is not enough.

Thanks, //Rob




More information about the devel mailing list