On Tue, Nov 19, 2019 at 09:34:37AM +0900, Keith Busch wrote: > On Mon, Nov 18, 2019 at 04:05:56PM -0800, Sagi Grimberg wrote: > > > > I'm starting to think we maybe need to get the connect out of the block > > layer execution if its such a big problem... Its a real shame if that is > > the case... > > We still need timeout handling for connect commands, so bypassing the > block layer will need to figure out some other way to handle that. > > This patch proposal doesn't really handle the timeouts very well either, > though: nvme_rdma_timeout() is going to end up referncing the wrong > queue rather than the one the request was submitted on. It doesn't > appear to really matter in the current code since it just resets the > entire controller, but if it ever wanted to do something queue specific... I am not sure it is an issue. Given timeout handler needs the queue for transporting the request exactly for handling timeout, right? Or when/what do you need the original submission queue for handling connect request timeout? Thanks, Ming
