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
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
