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 -- Rob Latham Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF Argonne National Labs, IL USA B29D F333 664A 4280 315B _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
