Padding is the number of bytes to shrink the destination chunk.
Example:
We have limit = 100bytes and padding = 5bytes
Then the returned chunk size will be limit - padding = 95bytes

A more obvious version of this function:

/// Gets chunk of size `limit - padding` and leaves remainder in buffer
pub fn get(&mut self, padding: usize) -> Vec<u8> {
  let mut chunk = std::mem::take(&mut self.buf);

  let target_size = self.limit - padding;
  if chunk.len() > target_size {
    // after this operation, chunk=0..target_size, self.buf=target_size..end
    self.buf = chunk.split_off(target_size);
  }
  return chunk;
}

I noticed that my original one had a mistake

Yeah, this allocation is a known problem (example).

This could be done with some unsafe pointer logic, but we're using Rust for a reason ;)

I think the problem is elsewhere. The returned chunk must be "moved out" to the response stream, so this memory should be considered "lost", we have no more control over it. Without reallocations, we lose a part of our buffer memory each time a chunk is retrieved. So if we have k chunks, we must perform k allocations for new chunks, or one huge allocation for all chunks (unknown number anyway).

And I think that we should care more about number of allocations/data copies rather than a total number of memory cells allocated, as data in the memory gets rotated, it doesn't grow up statically (sent responses are finally deallocated) so we won't end up with O(nk) allocated memory at once.

In this case, we're doing two-three memory operations per chunk:

1. extending buffer with new data (0-1 realloc, 1-2 copies, depending on prev capacity)
2. "moving out" chunk with std::mem::take - it allocs an empty Vec (1 alloc)
3. split off - (1 alloc, 1 copy) - see code (lines 2119-2128)

At this moment I cannot think of a better solution for this

If you're worried about memory size allocated for the buffer, I made some approximations.
Let's assume we're receiving 4MB chunks (gRPC limit) and have 1kB padding (likely real-world size). In this case, the buffer grows by 1kB for each chunk. It will reach 4MB (input chunk size) after 3999 chunks (nearly 16GB of data processed)