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

HG_Get_input_extra_buf giving back size = 0 #357

Open
mdorier opened this issue Apr 2, 2020 · 2 comments
Open

HG_Get_input_extra_buf giving back size = 0 #357

mdorier opened this issue Apr 2, 2020 · 2 comments

Comments

@mdorier
Copy link

mdorier commented Apr 2, 2020

I'm not sure if this is a bug or a misunderstanding on my part of what HG_Get_input_extra_buf does (the same behavior happens with HG_Get_ouput_extra_buf), but I can't seem to be able to allocate extra buffer space with those functions.

I am trying to bypass Mercury's serialization procedure by (1) registering the RPCs with NULL proc functions, (2) populating the handle's input buffer myself using HG_Get_input_buf (on client) and HG_Get_ouput_buf (on servers), (3) call HG_Get_input_extra_buf/HG_Get_ouput_extra_buf if the size returned by the HG_Get_input_buf/HG_Get_output_buf is not enought.

When the data fits in the eager buffer, the first difficulty I encountered is that Mercury is zero-ing these buffers prior to sending them, unless I use HG_Class_set_input_offset and HG_Class_set_output_offset to specify that I want a certain size to be used manually. The workaround I found was to call HG_Class_set_input_offset with the result of HG_Class_get_input_eager_size to tell Mercury I'm going to manually use the entire eager buffer.

When the data does not fit in the eager buffer, however, I have to call HG_Get_input_extra_buf, but this function always gives me a buffer size of 0. I tried using HG_Class_set_input_offset with a value larger than the eager buffer size, but it doesn't work, I still get 0.

Ideally, the behavior I would like to see is this:

  • Mercury does not zero the part of the eager buffer that is after the offset set by the user (as said above, I have a workaround, so it's not a priority)
  • The size argument of HG_Get_input_extra_buf/HG_Get_ouput_extra_buf should be an input argument, not an output argument, specifying the extra size I want to allocate.
@soumagne
Copy link
Member

soumagne commented Apr 2, 2020

HG_Get_input_extra_buf() will currently never "allocate" on its own, it will just return you a pointer to the extra payload buffer if there is one (on the receiving end). So currently that's right the get_extra_buf calls won't do what you are trying to do and you'd have to use hg_proc_save_ptr which is not really ideal I recognize that. So ok I will look to see if I can fix the behavior of those two calls.
Also I'm very surprised by that statement: "Mercury is zero-ing these buffers prior to sending them". We never memset any buffers to 0, we just re-use buffers as they are, so I'm not sure where that 0 comes from ?

Also the set_offset calls are here for you to define a custom header, that header size must fit in the eager message size, you should get an error if it's larger.

@mdorier
Copy link
Author

mdorier commented Apr 6, 2020

I don't know if Mercury is zeroing the buffer beyond the set offset before sending or when receiving, but here is an example of what happens:

  • client sets the input offset to 16 bytes, but puts data in the full buffer (in my case the eager input size is 4060)
  • server sets the input offset to 128 bytes. When receiving a RPC from the client, the content of the buffer has 16 bytes worth of data, followed by only zeroes.

It's possible that the client is simply not sending the 4060 bytes, only the data up to the specified offset.

@soumagne soumagne added this to the mercury-2.1.0 milestone Oct 23, 2020
@soumagne soumagne modified the milestones: mercury-2.1.0, mercury-2.1.1 Nov 3, 2021
@soumagne soumagne modified the milestones: mercury-2.2.0, mercury-2.3.0 Dec 9, 2022
@soumagne soumagne modified the milestones: mercury-2.3.0, future Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants