I think this is a question about what it means for an implementation to "ignore" an info hint. In this example, what if "foo = bar" was "invert_all_bits = true". It would probably be bad if the library returned that info key without actually doing what the user requested.
~Jim. On Mon, Oct 18, 2021 at 12:12 PM Raffenetti, Ken via mpi-forum < mpi-forum@lists.mpi-forum.org> wrote: > Here's an example program that illustrates the current file info behavior > with MPICH and Open MPI. Neither library will abort the application in my > tests. MPICH does not recognize the "foo" key, and I would guess the same > for Open MPI. > > So is this correct behavior according to the standard? Or a bug? There are > users who prefer the current behavior, I suspect in part because there is > no attribute caching interface for MPI file objects. > > #include <mpi.h> > #include <stdlib.h> > #include <stdio.h> > #include <string.h> > > int main(void) { > MPI_Init(NULL, NULL); > > MPI_Info info; > MPI_Info_create(&info); > MPI_Info_set(info, "foo", "bar"); > > MPI_File fh; > MPI_File_open(MPI_COMM_SELF, "testfile", MPI_MODE_RDWR | > MPI_MODE_CREATE, info, &fh); > > MPI_Info info_used; > MPI_File_get_info(fh, &info_used); > > char value[4] = ""; > int flag; > MPI_Info_get(info_used, "foo", 3, value, &flag); > > if (!flag) { > printf("key not found\n"); > MPI_Abort(MPI_COMM_WORLD, 1); > } > > if (strcmp(value, "bar")) { > printf("value does not match\n"); > MPI_Abort(MPI_COMM_WORLD, 1); > } > > MPI_File_close(&fh); > MPI_Info_free(&info); > MPI_Info_free(&info_used); > > MPI_Finalize(); > return 0; > } > > On 10/15/21, 2:47 PM, "mpi-forum on behalf of Raffenetti, Ken via > mpi-forum" <mpi-forum-boun...@lists.mpi-forum.org on behalf of > mpi-forum@lists.mpi-forum.org> wrote: > > We brought this to the forum because during our internal discussion is > was shown that ROMIO will return any "ignored" key/value pairs set by the > user in MPI_FILE_GET_INFO. Essentially, ROMIO duplicates the users info > object, and only adjusts settings for keys it recognizes. Perhaps this is > wrong behavior according to MPI-4.0? > > This behavior was introduced into ROMIO somewhat recently in May 2020. > There was a user request for it based on how OMPI-IO behaved. > https://github.com/pmodels/mpich/pull/3954 > > Ken > > On 10/13/21, 3:46 PM, "mpi-forum on behalf of Jim Dinan via mpi-forum" > <mpi-forum-boun...@lists.mpi-forum.org on behalf of > mpi-forum@lists.mpi-forum.org> wrote: > > Hi Rob, > This seems reasonable to me. I think you can draw an analogy to an > application setting "mpi_assert_no_any_tag = true" and checking the value > returned by MPI_Comm_get_info to decide whether to use MPI_ANY_TAG on the > communicator. I would suggest info values like "true" and "false" so that > ROMIO can return back the same value passed by the user if the info key is > accepted. > > As of MPI 4.0, MPI_File_get_info must return "all hints that are > supported by the implementation and have default values specified; any > user-supplied hints that were not ignored by the implementation; and any > additional hints that were set by the implementation." So, true/false would > also allow ROMIO to return a default value for the info key if the user > hasn't set it. > > One thing you can't do with info today is fail the operation > because of a key/value pair in the info argument. If there is an issue with > a particular key/value pair, it is supposed to be ignored. > > ~Jim. > > > On Mon, Oct 11, 2021 at 2:13 PM Latham, Robert J. via mpi-forum < > mpi-forum@lists.mpi-forum.org> wrote: > > > I'd like a way to tell users programmatically about features ROMIO > supports. > > One way I imagined doing so was through the info object, though > we're having some internal discussion about how kosher that is. Any > thoughts from the broader MPI community about an approach like this: > > > ``` > MPI_Info_create(&info); > MPI_Info_set(info, "romio_feature_xyz", "requested"); > MPI_File_open(...) > MPI_File_get_info(fh, &info_used) > MPI_File_get_info(info_used, "romio_feature_xyz", > MPI_MAX_INFO_VAL-1, > value, &flag); > > ``` > > Possible points of contention: > > - we have examples of using hints for clients to pass information > to implementations (striping_factor, cb_buffer_size) and examples of > implementations passing information to users (cb_nodes on Blue Gene), but > we don't have too many examples of two-way hints. > > - will MPI_File_get_info return all info keys or just the ones the > implementation understands? The standard dictates what is required to be > returned. ROMIO (so de facto standard) will return the union of its > internal keys and any keys (known or unknown) passed in by the user. > > - The use of "requested" as a hint value that the implementation > can then either set to "enabled" or "disabled" guards the situation where > a user code is passing these infos to an older MPI IO implementation. If > the hint comes back exactly as given, then the implementation ignored this > feature request and it is not supported. If the hint comes back "enabled" > then the caller knows something about the implementation. > > Thanks > ==rob > > > _______________________________________________ > mpi-forum mailing list > mpi-forum@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >
_______________________________________________ mpi-forum mailing list mpi-forum@lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum