On Sat, 7 Mar 2009 21:16:47 +0200 Sasha Khapyorsky <[email protected]> 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 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
