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

Should messages smaller than receive buffer be considered truncated? #104

Open
pentschev opened this issue Oct 17, 2023 · 0 comments
Open

Comments

@pentschev
Copy link
Member

pentschev commented Oct 17, 2023

We were until now considering TAG messages received that are smaller than the destination buffer to be truncated, which is how UCX-Py dealt with it. This behavior has been reverted in #105 until we decide on the proper behavior.

However, there are legitimate use case where the destination buffer may be smaller from the user's perspective, for example (but not limited to) when the user wants to receive a message that it is known to be the size of or smaller than the destination buffer.

Python users tend to use more high-level objects, in which cases knowing that a mismatch in size might be due to a potential user error, for example by mixing dtypes in NumPy the following is valid if we don't explicitly truncate, even if not intended by the user:

a = np.zeros(10, dtype=np.uint8)
server_ep.send(a)

b = np.zeros(10, dtype=np.unit64)
client_ep.recv(b)

Should any messages received on both C++ and Python UCXX APIs that are different than the buffer size provided by the user be considered truncated? Should we consider different behavior for C++ and Python?

pentschev added a commit to pentschev/ucxx that referenced this issue Oct 17, 2023
rapids-bot bot pushed a commit that referenced this issue Oct 20, 2023
See #104 for details.

Authors:
  - Peter Andreas Entschev (https://github.com/pentschev)

Approvers:
  - Lawrence Mitchell (https://github.com/wence-)

URL: #105
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

No branches or pull requests

1 participant