Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Michael Guralnik <michaelgur@nvidia.com>, linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next] IB/core: Add option to limit user mad receive list
Date: Thu, 4 Apr 2024 19:51:03 +0300	[thread overview]
Message-ID: <20240404165103.GW11187@unreal> (raw)
In-Reply-To: <20240404140113.GJ1723999@nvidia.com>

On Thu, Apr 04, 2024 at 11:01:13AM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 02, 2024 at 12:50:21PM +0300, Leon Romanovsky wrote:
> > From: Michael Guralnik <michaelgur@nvidia.com>
> > 
> > ib_umad is keeping the received MAD packets in a list that is not
> > limited in size. As the extraction of packets from this list is done
> > from user-space application, there is no way to guarantee the extraction
> > rate to be faster than the rate of incoming packets. This can cause to
> > the list to grow uncontrollably.
> > 
> > As a solution, let's add new ysfs control knob for the users to limit
> > the number of received MAD packets in the list.
> > 
> > Packets received when the list is full would be dropped. Sent packets
> > that are queued on the receive list for whatever reason, like timed out
> > sends, are not dropped even when the list is full.
> > 
> > Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> >  .../ABI/stable/sysfs-class-infiniband         | 12 ++++
> >  drivers/infiniband/core/user_mad.c            | 63 ++++++++++++++++++-
> >  2 files changed, 72 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband
> > index 694f23a03a28..0ea9d590ab0e 100644
> > --- a/Documentation/ABI/stable/sysfs-class-infiniband
> > +++ b/Documentation/ABI/stable/sysfs-class-infiniband
> > @@ -275,6 +275,18 @@ Description:
> >  		=============== ===========================================
> >  
> >  
> > +What:		/sys/class/infiniband_mad/umad<N>/max_recv_list_size
> > +Date:		January, 2024
> > +KernelVersion:	v6.9
> > +Contact:	linux-rdma@vger.kernel.org
> > +Description:
> > +		(RW) Limit the size of the list of MAD packets waiting to be
> > +		     read by the user-space agent.
> > +		     The default value is 0, which means unlimited list size.
> > +		     Packets received when the list is full will be silently
> > +		     dropped.
> 
> I'm really not keen on this as a tunable, when we get to future
> designs it may be hard to retain this specific behavior.
> 
> Why do we need a tunable? Can we just set it to something large and be
> done with it?

I don't know which value to set to be large enough from one side and
small enough to do not cause to OOM while host gets MAD packets.

Thanks

> 
> Jason
> 

  reply	other threads:[~2024-04-04 16:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02  9:50 [PATCH rdma-next] IB/core: Add option to limit user mad receive list Leon Romanovsky
2024-04-04 14:01 ` Jason Gunthorpe
2024-04-04 16:51   ` Leon Romanovsky [this message]
2024-04-05 12:58     ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240404165103.GW11187@unreal \
    --to=leon@kernel.org \
    --cc=jgg@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michaelgur@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox