[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