Re: Safe to delete rpcrdma.ko loading start-up code

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, May 21, 2024 at 07:10:53PM +0300, Sagi Grimberg wrote:
> 
> 
> On 21/05/2024 18:23, Jason Gunthorpe wrote:
> > On Tue, May 21, 2024 at 05:12:23PM +0300, Sagi Grimberg wrote:
> > > > > > > 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..
> > > > > nvme/nvmet/isert are requested by the kernel.
> > > > How? What is the interface to trigger request_module?
> > > On the host, writing to the nvme-fabrics misc device a comma-separated
> > > connection string
> > > contains a transport string, which triggers the corresponding module to be
> > > requested.
> > But how did nvme-fabrics even get loaded to write to it's config fs in
> > the first place?
> 
> Something (/etc/modules-load?) loaded it intentionally.
> That something knows about a concrete intention to use nvme though...

This mechanism we are talking about is an add-on to /etc/modules-load
that only executes if rdma HW is present.

This is why it is a good place to load nvme-fabrics stuff, if you
don't have rdma HW then you know you don't need it.

Autoloading is the version where you do 'mount -tnfs -o=rdma' and the
kernel automatically request_module's nfs and then nfs-rdma based only
on the command line options.

I'm not sure this is even possible with configfs as the directories
you need to write into don't even exist until the module(s) are
loaded, right?

Jason