On Thu, Jul 19, 2018 at 08:04:09AM -0700, James Smart wrote:
> Which I'm going to say no on. I originally did the abort before the reset
> and it brought out some confusion in the reset code. Thus the existing flow
> which just resets the controller which has to be done after the abort
> anyway.
O
On 7/19/2018 7:54 AM, Johannes Thumshirn wrote:
On Thu, Jul 19, 2018 at 04:50:05PM +0200, Christoph Hellwig wrote:
The upper layer is only going to retry after tearing down the transport
connection. And a tear down of the connection MUST clear all pending
commands on the way. If it doesn't we
On 7/19/2018 7:10 AM, Johannes Thumshirn wrote:
On Thu, Jul 19, 2018 at 03:42:03PM +0200, Christoph Hellwig wrote:
Without even looking at the code yet: why? The nvme abort isn't
very useful, and due to the lack of ordering between different
queues almost harmful on fabrics. What problem do
On Thu, Jul 19, 2018 at 04:50:05PM +0200, Christoph Hellwig wrote:
> The upper layer is only going to retry after tearing down the transport
> connection. And a tear down of the connection MUST clear all pending
> commands on the way. If it doesn't we are in deep, deep trouble.
>
> A NVMe abort
On Thu, Jul 19, 2018 at 04:35:34PM +0200, Johannes Thumshirn wrote:
> > No with the the code following what we have in PCIe that just means
> > we'll eventually controller reset after the I/O command times out
> > the second time as we still won't have seen a completion for it.
>
> Exactly that wa
On Thu, Jul 19, 2018 at 04:23:55PM +0200, Christoph Hellwig wrote:
> On Thu, Jul 19, 2018 at 04:10:25PM +0200, Johannes Thumshirn wrote:
> > The problem I'm trying to solve here is really just single commands
> > timing out because of i.e. a bad switch in between which causes frame
> > loss somewhe
On Thu, Jul 19, 2018 at 04:10:25PM +0200, Johannes Thumshirn wrote:
> The problem I'm trying to solve here is really just single commands
> timing out because of i.e. a bad switch in between which causes frame
> loss somewhere.
And that is exactly the case where NVMe abort does not actually work
i
On Thu, Jul 19, 2018 at 03:42:03PM +0200, Christoph Hellwig wrote:
> Without even looking at the code yet: why? The nvme abort isn't
> very useful, and due to the lack of ordering between different
> queues almost harmful on fabrics. What problem do you try to
> solve?
The problem I'm trying to
On Thu, Jul 19, 2018 at 03:28:34PM +0200, Johannes Thumshirn wrote:
> PCI currently is the only transport we have which is doing more than
> queueing a transport reset but trying to abort the command first.
>
> This series brings the other transports we currently have up to the
> same level.
With
PCI currently is the only transport we have which is doing more than
queueing a transport reset but trying to abort the command first.
This series brings the other transports we currently have up to the
same level.
On FC we can prepend a third escalation level by first to abort the FC
operation b
10 matches
Mail list logo
