Re: [PATCH net-next v6 08/12] net: homa: create homa_incoming.c

[John Ousterhout <ouster@cs.stanford.edu>]

On Tue, Feb 4, 2025 at 12:50 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 2/4/25 12:33 AM, John Ousterhout wrote:
> > On Mon, Feb 3, 2025 at 1:12 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >> 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.

> >> 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)?

> > 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-