On Tue, Feb 4, 2025 at 12:50 AM Paolo Abeni [off-list ref] wrote:
On 2/4/25 12:33 AM, John Ousterhout wrote:
quoted
On Mon, Feb 3, 2025 at 1:12 AM Paolo Abeni [off-list ref] wrote:
quoted
I don't see where/how the SO_HOMA_RCVBUF max value is somehow bounded?!?
It looks like the user-space could pick an arbitrary large value for it.
That's right; is there anything to be gained by limiting it? This is
simply mmapped memory in the user address space. Aren't applications
allowed to allocate as much memory as they like? If so, why shouldn't
they be able to use that memory for incoming buffers if they choose?
If unprivileged applications could use unlimited amount of kernel
memory, they could hurt the whole system stability, possibly causing
functional issue of core kernel due to ENOMEM.
The we always try to bound/put limits on amount of kernel memory
user-space application can use.
Homa's receive buffer space is *not kernel memory*; it's just a large
mmapped region created by the application., no different from an
application allocating a large region of memory for its internal
computation.
quoted
quoted
Fine tuning controls and sysctls could land later, but the basic
constraints should IMHO be there from the beginning.
OK. I think that SO_HOMA_RCVBUF takes care of RX buffer space.
We need some way to allow the admin to bound the SO_HOMA_RCVBUF max value.
Even if this memory is entirely user memory (we seem to be
miscommunicating over this)?
quoted
For TX, what's the simplest scheme that you would be comfortable with? For
example, if I cap the number of outstanding RPCs per socket, will that
be enough for now?
Usually the bounds are expressed in bytes. How complex would be adding
wmem accounting?
I'll see what I can do.
-John-