[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