[ofa-general] [PATCH 11/10] libibmad:infiniband-diags: deprecate madrpc_set_[retries|timeout] WAS: [PATCH 1/10] libibmad: Clean up "new" interface

Ira Weiny weiny2 at llnl.gov
Tue Mar 10 16:34:26 PDT 2009


On Sat, 7 Mar 2009 21:16:47 +0200
Sasha Khapyorsky <sashak at voltaire.com> wrote:

> On 11:11 Mon 02 Mar     , Ira Weiny wrote:
> > 
> > I see this as well.  Right now libibmad is designed around the "run and exit"
> > diag model but we are moving it toward a library which can be used in more
> > complex applications.  We should push to do this once and as correct as
> > possible.
> 
> We can support both models, but we shouldn't complicate existing one, so
> enforcing all existing utils to call explicitly mad_rpc_set_timeout()
> is not a good idea IMO.

Ok, As I said in a previous email looking deeper makes this more complicated.
I think to really fix it we will have to bump the library version.  This is
because there are currently 2 general ways to specify a timeout, via global
lib setting (madrpc_set_timeout) and via function parameter.  The second way
is further broken down into a via struct or a named "timeout" param.  So there
are kind of 3 ways to set this.

In the diags they set the global and ibd_timeout to the same value and then
use ibd_timeout where a "timeout" param is expected.  Thereby setting the
timeout the same for all calls.

I will look at documenting the above as technically it is possible to change
the timeout on various ports by setting the parameters appropriately on each
call.  I don't like this going forward but I guess it is doable without
changing the interface.

> BTW, this patch now breaks most of infiniband-diags tools when timeout is
> not specified in command line explicitly with '-t'. The default used is
> ibd_timeout, which is '0' and umad_send() fails with 'Resource
> temporarily unavailable'.
>

Yep, missed that.

Ira




More information about the general mailing list