[Mpi-forum] mpi info behavior
Jim Dinan
james.dinan at gmail.com
Mon Oct 18 13:22:40 CDT 2021
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 at 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-bounces at lists.mpi-forum.org on behalf of
> mpi-forum at 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-bounces at lists.mpi-forum.org on behalf of
> mpi-forum at 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 at 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 at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20211018/b8c0cbfb/attachment.html>
More information about the mpi-forum
mailing list