[PATCH] nvmet: allow setting ctrl to ready without iosqes/iocqes set

[Anner, Ran]

Reviving this thread.

-----Original Message-----
From: Christoph Hellwig <hch at lst.de> 
Sent: Tuesday, May 11, 2021 19:34
To: Anner, Ran
Cc: Christoph Hellwig
Subject: Re: [PATCH] nvmet: allow setting ctrl to ready without iosqes/iocqes set


[EXTERNAL EMAIL] 

Please resend the mail with the mainling list in the loop.

On Mon, May 10, 2021 at 12:27:36PM +0000, Anner, Ran wrote:
> Hi Christoph.
> 
> This is for IO controller.
> We saw a host behavior where only the cc.en bit was set and the host was waiting for csts to indicate ready state.
> >From what I saw in the nvme specification we should only fail connect commands that create IO queues in case IOSQES/IOCQES is not set and csts should not be effected.
> 
> Thanks
> 
> -----Original Message-----
> From: Christoph Hellwig <hch at lst.de>
> Sent: Tuesday, May 4, 2021 12:13
> To: Anner, Ran
> Cc: hch at lst.de; linux-nvme at lists.infradead.org
> Subject: Re: [PATCH] nvmet: allow setting ctrl to ready without 
> iosqes/iocqes set
> 
> 
> [EXTERNAL EMAIL]
> 
> On Sun, May 02, 2021 at 06:31:06PM +0300, ran.anner at dell.com wrote:
> > From: Ran Anner <Ran.Anner at dell.com>
> > 
> > According to the spec we should fail creation of IO queues if iosqes 
> > or iocqes properties are not set but does not mention preventing 
> > from changing ctrl status to ready.
> > We have seen host implementation which sets the property to 0x1 and 
> > waits endlessly until ctrl status changes to ready.
> 
> So is that for a discovery controller?  The spec says the field shall be read-only for them, although we don't reject writes to the property right now.
---end quoted text---