All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <kbusch@kernel.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: "Belanger, Martin" <Martin.Belanger@dell.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: Clarification regarding "nvme discover" and setting IOSQES/IOCQES
Date: Mon, 8 Feb 2021 20:28:37 -0700	[thread overview]
Message-ID: <20210209032837.GA99682@C02WT3WMHTD6> (raw)
In-Reply-To: <cbf91356-e2b4-692b-38d8-22ec00359b8e@grimberg.me>

On Mon, Feb 08, 2021 at 03:01:28PM -0800, Sagi Grimberg wrote:
> 
> > > > Hi Sagi,
> > > > 
> > > > Yes. The Discovery Controller currently allows it. The problem, however,
> > > > is that the DC seems to be expecting these values to be non-zero.
> > > > 
> > > > I tried setting IOCQES=0 and IOSQES=0, which the DC allows (i.e. Prop
> > > > Set return status=0). However, when I follow this by a "Property Get -
> > > > Controller Status", the Status now shows "Controller Fatal Status (CFS)"
> > > > (see Base specs - Figure 79).
> > > 
> > > Yes, the oversight extends to the target that expects it (shared code
> > > with I/O controllers).
> > > 
> > > Does this fix your issue?
> > 
> > Seems like the Identify Controller SQES and CQES fields ought to be
> > updated too, but the spec isn't clear on this. Feels like ECN
> > material...
> 
> Yes, we should start with this patch though right?

Yep, your patch looks good.

I was just thinking a generic implementation could align the CC settings with
the ID_CTRL values rather than checking for a discovery controller, but I
noticed the spec didn't provide us that opportunity. That was actually a
misguided thought anyway since we don't even have ID_CTRL data on the initial
CC setting! :)

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

      reply	other threads:[~2021-02-09  3:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 16:32 Clarification regarding "nvme discover" and setting IOSQES/IOCQES Belanger, Martin
2021-02-08 18:16 ` Sagi Grimberg
     [not found]   ` <SJ0PR19MB454412891E589E03EF8DB948F28F9@SJ0PR19MB4544.namprd19.prod.outlook.com>
2021-02-08 18:59     ` Sagi Grimberg
2021-02-08 19:04       ` Keith Busch
2021-02-08 23:01         ` Sagi Grimberg
2021-02-09  3:28           ` Keith Busch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210209032837.GA99682@C02WT3WMHTD6 \
    --to=kbusch@kernel.org \
    --cc=Martin.Belanger@dell.com \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.