All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: Safe to delete rpcrdma.ko loading start-up code
Date: Tue, 21 May 2024 09:43:06 -0300	[thread overview]
Message-ID: <20240521124306.GE20229@nvidia.com> (raw)
In-Reply-To: <8cc80bdb-9f17-4f44-b2e6-54b36ac85b63@grimberg.me>

On Tue, May 21, 2024 at 12:04:02PM +0300, Sagi Grimberg wrote:
> 
> 
> On 20/05/2024 21:05, Chuck Lever III wrote:
> > Hi-
> > 
> > I've tested this with two kinds of systems:
> > 
> > 1. A system with no physical RDMA devices and no start-up
> >     scripts to load these modules
> > 
> > 2. A system with physical RDMA devices and with the start-up
> >     scripts that load xprtrdma/svcrdma
> > 
> > In both cases, after doing an "rmmod rpcrdma", I can mount
> > a "proto=rdma" mount or start the NFS server, and the module
> > gets reloaded automatically.
> > 
> > I therefore believe it is safe to delete the code in the
> > rdma-core start-up scripts that manually load RPC-related
> > RDMA support. Either the sunrpc.ko module does this, or NFS
> > user space handles it. There's no need for the rdma-core
> > scripting.
> 
> I didn't know that rdma-core does this... it really shouldn't, the
> mount should (and does) handle it.

This is new, it didn't used to do this

> I also see that srp(t) and iser(t) are loaded too.. IIRC these are
> loaded by their userspace counterparts as well (or at least they
> should).

And AFIAK, these don't have a way to autoload at all. autoload
requires the kernel to call request_module..

ipoib is also a problem, we don't have a way to autoload it either

Jason

  reply	other threads:[~2024-05-21 12:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-20 18:05 Safe to delete rpcrdma.ko loading start-up code Chuck Lever III
2024-05-21  9:04 ` Sagi Grimberg
2024-05-21 12:43   ` Jason Gunthorpe [this message]
2024-05-21 13:05     ` Sagi Grimberg
2024-05-21 13:37       ` Jason Gunthorpe
2024-05-21 14:12         ` Sagi Grimberg
2024-05-21 15:23           ` Jason Gunthorpe
2024-05-21 16:10             ` Sagi Grimberg
2024-05-21 16:37               ` Jason Gunthorpe
2024-05-21 20:30                 ` Sagi Grimberg
2024-05-21 23:29                   ` Jason Gunthorpe
2024-05-22 10:50                     ` Sagi Grimberg
2024-05-22  7:57                   ` Zhu Yanjun

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=20240521124306.GE20229@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sagi@grimberg.me \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.