The retry delay made sense when the only course of action fcoemon had was to destroy the FCoE instance. Now that it uses disable/enable during temporary DCB events, it should disable the interfaces as soon as an error is detected in the DCB configuration. Otherwise the fcoe stack continues to run traffic to a switch that may be dropping everything until the DCB state is corrected.
Signed-off-by: Chris Leech <[email protected]> --- fcoemon.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/fcoemon.c b/fcoemon.c index 08d105e..11a7ac2 100644 --- a/fcoemon.c +++ b/fcoemon.c @@ -2157,12 +2157,11 @@ static void fcm_netif_advance(struct fcm_netif *ff) fcm_dcbd_state_set(ff, FCD_INIT); break; case FCP_ERROR: - if (ff->dcbd_retry_cnt < DCBD_MAX_REQ_RETRIES) { + fcp_action_set(ff->ifname, FCP_DISABLE_IF); + if (ff->dcbd_retry_cnt < DCBD_MAX_REQ_RETRIES) fcm_dcbd_state_set(ff, FCD_ERROR); - } else { - fcp_action_set(ff->ifname, FCP_DISABLE_IF); + else fcm_dcbd_state_set(ff, FCD_INIT); - } break; case FCP_WAIT: default: _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
