On 21/05/2024 16:37, Jason Gunthorpe wrote:
On Tue, May 21, 2024 at 04:05:05PM +0300, Sagi Grimberg wrote:
On 21/05/2024 15:43, Jason Gunthorpe wrote:
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..
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.
On the target-side, configuring a port transport, also triggers in a
similar way...
iser is loaded by iscsiadm.
Yuk :\
Different strokes for different folks...
IIRC srp had a userspace daemon loading it.
srp-daemon requires it already loaded AFAIK
OK, so that one is the exception...
