[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rdma
Subject:    Re: [PATCH] opensm/osm_sm_mad_ctrl.c: In sm_mad_ctrl_send_err_cb,
From:       Sasha Khapyorsky <sashak () voltaire ! com>
Date:       2009-12-30 19:37:01
Message-ID: 20091230193701.GA26940 () me
[Download RAW message or body]

On 11:14 Wed 30 Dec     , Hal Rosenstock wrote:
> >> > '--resweep-on-failed-attr=11,15' (with reasonable default) will be more
> >> > useful for dealing with this and maybe another potential issues.
> >>
> >> Where else do you see this as being useful ?
> >
> > In this case at least. I had some questions in the past about how
> > to ignore some sort of initialization errors.
> 
> What (other) initialization errors should be ignored ? Isn't this
> dangerous and slippery slope ?

This is what we have now:

	    (p_smp->attr_id == IB_MAD_ATTR_PORT_INFO ||
	     p_smp->attr_id == IB_MAD_ATTR_MCAST_FWD_TBL ||
	     p_smp->attr_id == IB_MAD_ATTR_SWITCH_INFO ||
	     p_smp->attr_id == IB_MAD_ATTR_LIN_FWD_TBL ||
	     p_smp->attr_id == IB_MAD_ATTR_P_KEY_TABLE)) {
		OSM_LOG(p_ctrl->p_log, OSM_LOG_ERROR, "ERR 3119: "
			"Set method failed for attribute 0x%X (%s)\n",
			cl_ntoh16(p_smp->attr_id),
			ib_get_sm_attr_str(p_smp->attr_id));
		p_ctrl->p_subn->subnet_initialization_error = TRUE;
	}

Of course ignoring an errors can be dangerous, and useful for debugging
and sometimes to workaround buggy hardware issues.

> > Another potential use is
> > to extended this to SubnGet() responses errors handling too when
> > requested.
> 
> That would require additional changes beyond what is being discussed
> here and might not come from the same attribute list so it's unclear
> to me whether or not this is related (in terms of configuration).

Correct, it would be yet another addition, but in the same direction.
You can see this as not immediately related to the change in discussion.

> > Anyway it is better than introducing '--qos-init-error',
> > ('--pkey-init-error', etc.) and not much harder to implement.
> 
> Sure; the question was it's necessity and not it's implementation "difficulty.

Whole point was to not introduce a new options like
"--workaround-buggy-feature-X". But instead in cases when a quirks
avoidance is impossible at least to make it in more generic fashion
potentially useful for another things too.

Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]