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

Joe Eykholt joe.eykholt at gmail.com
Sat Jan 22 03:36:38 UTC 2011


On Fri, Jan 21, 2011 at 5:25 PM, Robert Love <robert.w.love at intel.com>wrote:

> 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
>

Yes, I think that's right.  It means the other end has proceeded far enough
to be sending beacons and we can receive them.  In particular I think
the LLD may need to register its MAC address after the claim.

I don't remember all the cases, but I think there
was some concern that even if someone sent out a claim notification there
could still be a conflict or a non-reachability issue.

        Joe



More information about the devel mailing list