All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhu Yanjun <yanjun.zhu@linux.dev>
To: Sagi Grimberg <sagi@grimberg.me>, Jason Gunthorpe <jgg@nvidia.com>
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: Wed, 22 May 2024 09:57:27 +0200	[thread overview]
Message-ID: <573f7e57-7599-4540-9dd7-622f7eedde79@linux.dev> (raw)
In-Reply-To: <0f9ddfe5-67ff-470b-8901-d513dceb757e@grimberg.me>

在 2024/5/21 22:30, Sagi Grimberg 写道:
> 
> 
> On 21/05/2024 19:37, Jason Gunthorpe wrote:
>> 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.
> 
> Still does not mean you want to use all the ulps though...
> 
>>
>> 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.
> 
> Do I want to autoload nvme-fabrics if I have a nvme device? do I want
> autoload nvme-tcp if I have an ethernet nic? maybe wlan nic is also a
> sufficient reason?
> 
> I just don't see why the presence of an rdma device dictates that all 
> the ulps
> autoload. Does rxe/siw count as rdma HW?

RXE/SIW can be auto loaded with the command "rdma link ...".
And some kernel modules, for example ib_core.ko, udp_tunnel.ko, 
ip6_udp_tunnel.ko and ib_uverbs.ko, are also auto-loaded when rxe/siw 
kernel modules are loaded.

RXE/SIW are emulation RDMA kernel drivers. They are based on NIC HW. 
Normally all the NICs can support RXE/SIW RDMA drivers because RXE/SIW 
do not require additional NIC features.

To now almost all the NIC HW can support RXE/SIW, even some virtual NICs 
can also support RXE/SIW, for example, bonding, TUN and veth.

Zhu Yanjun

> 
>>
>> 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?
> 
> Right. The entry-point of the subsystem needs to be loaded (nvmet is 
> loaded by nvmetcli),
> the individual transports/drivers are auto-selected.


      parent reply	other threads:[~2024-05-22  7:57 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
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 [this message]

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=573f7e57-7599-4540-9dd7-622f7eedde79@linux.dev \
    --to=yanjun.zhu@linux.dev \
    --cc=chuck.lever@oracle.com \
    --cc=jgg@nvidia.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.