Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: keith.busch@intel.com (Keith Busch)
Subject: nvme-cli argument passing for connect-all
Date: Mon, 11 Feb 2019 13:06:23 -0700	[thread overview]
Message-ID: <20190211200623.GE4525@localhost.localdomain> (raw)
In-Reply-To: <32dcb074-8d23-db13-9074-d0a8619b8baa@suse.de>

On Mon, Feb 11, 2019@03:34:23PM +0100, Hannes Reinecke wrote:
> Hi Keith,
> 
> I've come across a bit of an awkward issue, and I really would like some
> clarification on how to move forward.
> 
> Thing is, for 'connect-all' we have to pass _all_ arguments (for connect
> _and_ discovery), yet not every argument is valid for both calls.
> Which means if we enable nvme-cli to accept the superset of those arguments
> one or the other call will fail.
> (Case in point: 'keep-alive-tmo' will return an error for discovery
> controllers, so we cannot set it when calling 'connect-all').
> 
> We now have two ways of solving it:
> 
> Either blank the incorrect options from nvme-cli, and ensure that we're only
> setting the valid options.
> However, when doing so we will have to keep nvme-cli in sync with the
> kernel, otherwise we'll never be setting this option even if at some later
> time one of these options becomes valid.
> 
> Or we can simply ignore the options from the kernel parser, giving us some
> more leeway when updating either side.
> (Case in point: the kernel will ignore the 'nr_io_queues' argument for
> discovery controllers)
> 
> Can we please decide on a common policy how to handle invalid arguments?
> Like accept _all_ known arguments for both, discovery _and_ connect, and
> only return errors for unknown arguments?
> 
> Cheers,
> 
> Hannes

Hi Hannes,

IMO, I think we should make the kernel handle this and ignore entries that
don't apply. The discovery controller seems to be the special case here,
and we don't even handle it consistently. For example, a discovery_nqn
will ignore nr_io_queues parms, but will consider KATA an error. Why
the difference there?

Thanks,
Keith

  reply	other threads:[~2019-02-11 20:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 14:34 nvme-cli argument passing for connect-all Hannes Reinecke
2019-02-11 20:06 ` Keith Busch [this message]
2019-02-12  7:06   ` Hannes Reinecke

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=20190211200623.GE4525@localhost.localdomain \
    --to=keith.busch@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox