[PATCH 1/2] nvmet-rdma: avoid circular locking dependency on install_queue()

Sagi Grimberg sagi at grimberg.me
Mon Dec 4 02:19:54 PST 2023



On 11/20/23 15:48, Sagi Grimberg wrote:
> 
>>> According to 777dc82395de ("nvmet-rdma: occasionally flush ongoing
>>> controller teardown") this is just for reducing the memory footprint.
>>> Wonder if we need to bother, and whether it won't be better to remove
>>> the whole thing entirely.
>>
>> Well, Sagi added it, so I'll let him chime in on the usefulness.
> 
> While I don't like having nvmet arbitrarily replying busy and instead
> have lockdep simply just accept that its not a deadlock here, but we can
> simply just sidetrack it as proposed I guess.
> 
> But Hannes, this is on the other extreme.. Now every connect that nvmet
> gets, if there is even a single queue that is disconnecting (global
> scope), then the host is denied. Lets give it a sane backlog.
> We use rdma_listen backlog of 128, so maybe stick with this magic
> number... This way we are busy only if more than 128 queues are tearing
> down to prevent the memory footprint from exploding, and hopefully it is
> rare enough that the normal host does not see an arbitrary busy
> rejection.
> 
> Same comment for nvmet-tcp.

Hey Hannes, anything happened with this one?

Overall I think that the approach is fine, but I do think
that we need a backlog for it.



More information about the Linux-nvme mailing list