All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel.verkamp@intel.com (Daniel Verkamp)
Subject: NVME-CLI : Fabrics property-get and 64 bit property (CAP)
Date: Tue, 19 Jun 2018 10:54:20 -0700	[thread overview]
Message-ID: <e75d7829-9aeb-90fb-249a-c7ac4cef10bd@intel.com> (raw)
In-Reply-To: <CAPrnrPD2PtPO38cAzMfKdhS18GFj1vk032p0h0rQf0CFP+R=cw@mail.gmail.com>

On 06/19/2018 09:23 AM, Eyal BenDavid wrote:
> Hi all,
> 
> We use show-regs in NVME-CLI for fabrics (FC) property-get (CAP, CC etc)
> 
> The controller capabilities property (CAP) is 64 bit.
> 
> The result field of struct nvme_passthru_cmd is of type __u32
> 
> Therefore the following code snippet from file nvme-ioctl.c,
> function nvme_property() might lose information:
> 
> Code:
>    /*   __le64 *value  */
> 
>     err = nvme_submit_admin_passthru(fd, &cmd);
>     if (!err && fctype == nvme_fabrics_type_property_get)
>         *value = cpu_to_le64(cmd.result);    // <<<<<<  HERE
> 
> When running show-regs command the high dword of CAP is always 0.
> 
> My questions:
> how can I use nvme-cli to get the whole 8 byte range for CAP property
> in property-get command.
> Can I get the missing dword by an additional call to offset 4? (using
> admin-passtru)
> Is it legal for the controller to answer for this request?

I don't know the answer to the nvme-cli question above, but it seems
like struct nvme_completion is insufficient to represent the Property
Get response, since it only has a 32-bit result field, as you mentioned.

For the question about retrieving CAP via 4-byte accesses, I don't think
this is allowed.  NVMe-oF 1.0 base spec section 3.5.1 (Property
Definitions) says: "The host shall access properties in their native
width with an offset that is at the beginning of the property."

Thanks,
-- Daniel

  reply	other threads:[~2018-06-19 17:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 16:23 NVME-CLI : Fabrics property-get and 64 bit property (CAP) Eyal BenDavid
2018-06-19 17:54 ` Daniel Verkamp [this message]
2018-06-19 19:02   ` Eyal BenDavid
2018-06-19 19:48     ` Keith Busch
2018-06-19 20:00       ` Eyal BenDavid
2018-06-19 20:25         ` Keith Busch
2018-06-19 20:55           ` Eyal BenDavid
2018-06-19 21:33             ` Eyal BenDavid
2018-06-20 16:20               ` Eyal BenDavid

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=e75d7829-9aeb-90fb-249a-c7ac4cef10bd@intel.com \
    --to=daniel.verkamp@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 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.