On Mon, 2010-08-30 at 15:07 -0700, Joe Eykholt wrote: > On 8/30/10 2:43 PM, Robert Love wrote: > > On Mon, 2010-08-30 at 21:26 +0000, Bhanu Gollapudi wrote: > >> In fcoe_ctlr_els_send, we determine to be in FIP or non-FIP mode based > >> on fip->flogi_count, and at the 3rd unsuccessful FLOGI attempt, we fall > >> back to non-FIP mode. This takes around 8 secs time. So we expect a FIP > >> discovery advertisement from the switch within 8 secs to not fall back > >> to non-FIP mode. > >> > >> I think this is too less a time to give up FIP mode, as when RSTP > >> protocol is enabled in the switch I've seen the cases where the switch > >> can take a little longer than 8 secs to send a discovery advertisement, > >> even though the FKA_ADV_PERIOD is default 8 secs. We can also have > >> problems when the switch administrator changes the default value to > 8 > >> secs. > >> > >> I think we should have reasonably high FIP FLOGI retries (10 ??) before > >> falling back to non-FIP mode. > >> > >> Please let me know your thoughts. > > The intention, and I think it still works this way, is that we don't > settle on FIP or non-FIP until either: we successfully login via non-FIP > OR we receive a FIP frame (usually an advertisement, solicited or not).
> The current code drops the first one or two non-FIP FLOGI requests to give FIP > a chance if both were supported (most switches wouldn't), but after that, > even though it will send out non-FIP FLOGI requests, it can still operate > in FIP mode if it receives a FIP frame. Issue I'm seeing with the switch is that, when RSTP is enabled, it wouldnt send the discovery advertisement for around 10 secs. In the meantime 2 FLOGIs were dropped, and then the driver goes into non-FIP mode and sends FC FLOGI, instead of FIP FLOGI, which the switch accepts. Eventually, the switch would send discovery advertisement, but its too late and the driver would continue in non-FIP mode until there is link event. This behavior to me is inconsistent as sometimes it logs into the switch in FIP mode and sometimes in non-FIP mode. > > As long as the libfc lport keeps trying to send out FLOGIs, it should be > fine. Another thing we could do is to reset the lport after selecting > an FCF (if we don't already do that) so that it restarts its FLOGI attempts. > > > I think that increasing the retry count would help a lot, but there > > could still be a race depending on the switch's behavior. An alternative > > would be to get rid of non-FIP mode completely. Now that there is VN2VN > > for point-to-point mode, I don't see the necessary of non-FIP mode. I'm > > a bit reluctant to yank it out completely though, I seem to think that > > fnic is using non-FIP mode in some case(s). [ Joe correct me if I'm > > wrong on this ] > > Right, we do need non-FIP mode for fnic for now. > > > One option that we've tossed around here is to set the default mode to > > FIP-only in fcoe.ko. That way another LLD could override it, but it > > would be FIP-only for netdev based drivers. > > That would be OK with me. I'm sorry, I may be missing something here. Are we referring to FIP_MODE_AUTO as FIP-only mode? In that case, if fip->mode is FIP_MODE_AUTO, we can infinitely retry for FIP FLOGI instead of falling back to non-FIP mode (ignoring flogi_count) in fcoe_ctlr_else_send(). That way LLDs can get rid of non-FIP mode completely based on the mode with which they init the ctlr. Is this acceptable? > > Joe > > _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
