Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prov/util, shm: fix util srx to adhere to peer api (setting msg_size and flags correctly) #10511

Merged
merged 2 commits into from
Nov 13, 2024

Conversation

aingerson
Copy link
Contributor

fix util_srx implementation to properly set msg_size and flags and remove setting in shm

The peer srx should return entries with the FI_MSG/FI_TAGGED and
FI_RECV flags set

The msg_size field in the peer_rx_entry needs to be set in the
expected path to the number of bytes allowed to be copied.
This is either the size of the message (from the attr->msg_size
paramter) or, if the buffer is not large enough to hold the entire
message, the size of the buffer.

This also fixes setting the message size and flag fields on the unexpected
multi receive path. This case is a bit different because it not only has to
account for the message size and buffer size, but also for the owner entry's message
size and flags

Signed-off-by: Alexia Ingerson <alexia.ingerson@intel.com>
The util srx/peer srx should return the entry with the op flags
(FI_MSG/FI_TAGGED + FI_RECV) already set. Remove from the shm code

Signed-off-by: Alexia Ingerson <alexia.ingerson@intel.com>
@aingerson
Copy link
Contributor Author

@shijin-aws @amirshehataornl Any thoughts or concerns?

Copy link
Contributor

@j-xiong j-xiong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


rx_entry->peer_entry.iov[0].iov_base =
mrecv_entry->peer_entry.iov->iov_base;
rx_entry->peer_entry.iov->iov_len =
Copy link
Contributor

@shijin-aws shijin-aws Nov 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit strange that we use iov[0] for iov_base while iov-> for iov_len. Is it enforced that multi_recv post has to be 1 iov_count?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, current util code only supports iov_count == 1 for multi_recv. See the assertion in util_generic_mrecv

	assert(flags & FI_MULTI_RECV && iov_count == 1);

@aingerson aingerson merged commit fc24cad into ofiwg:main Nov 13, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants