[Pvfs2-developers] BMI_set_info and very picky GM

[Phil Carns]

I vote for the MPI-IO approach, where unknown/unsupported options are 
silently ignored.  It the setinfo implementations could still return 
ENOSYS by default; as long as this doesn't trigger an automatic gossip 
complaint the caller then has the option to decide whether to check the 
return code or not.

-Phil

Robert Latham wrote:
> On Jazz, where we build PVFS2 to only use GM communication, the calls
> to BMI_set_info to set BMI_TCP_BUFFER_SEND_SIZE return ENOSYS.  This
> has the unfortunate side effect of spewing a long backtrace to the
> client (that's specific to the way GM handles unrecognized hints.  IB
> just prints a waring), but since nothing checks the return value of
> BMI_set_info, the client continues to operate and the program
> completes w/o errors.  
> 
> Are BMI_set_info calls supposed to be like MPI_set_info, where any
> hints we do not understand are silently ignored?  Or should
> BMI_set_info be more picky, and warn when an unknown hint is passed to
> a BMI implementation?
> 
> In the former, tuning parameters specific for one implementation (like
> BMI_TCP_BUFFER_SEND_SIZE) need not bother the info processing of other
> BMI implentations (i.e. there is no good analog of
> BMI_TCP_BUFFER_SEND_SIZE in GM land, and even if there were, we should
> pick a more generally-named hint). 
> 
> In the later, callers are not suprised if they passed in a hint they
> though was supported but is in fact not.  
> 
> I suspect I'm biased towards doing things the MPI-IO way:  Are there
> good reasons to enumerate all known info options in each and every BMI
> implementation?  
> 
> ==rob
>