All of lore.kernel.org
 help / color / mirror / Atom feed
From: Klaus Jensen <its@irrelevant.dk>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org, Klaus Jensen <k.jensen@samsung.com>,
	Max Reitz <mreitz@redhat.com>, Klaus Jensen <its@irrelevant.dk>,
	Keith Busch <kbusch@kernel.org>
Subject: [PATCH 0/3] hw/block/nvme: mdts/zasl cleanup
Date: Mon, 22 Feb 2021 21:29:18 +0100	[thread overview]
Message-ID: <20210222202921.92774-1-its@irrelevant.dk> (raw)

From: Klaus Jensen <k.jensen@samsung.com>

The gist of this series is about aligning the zoned.zasl parameter with
the mdts parameter. I complained about this back when I was reviewing
the zoned series but was shot down. I relented on the size/capacity
debate (and still fully support that), but I never really liked that
ZASL is different from MDTS. Changing the definition makes the
validation code much simpler and, well, it aligns perfectly with the
existing mdts parameter, which is the goal here.

While the current definition of zasl is in master, it has not yet been
released, so this is sort of our last chance to change this before v6.0.

I'll repeat the commit message of [3/3] here for context:

ZASL (Zone Append Size Limit) is defined exactly like MDTS (Maximum Data
Transfer Size), that is, it is a value in units of the minimum memory
page size (CAP.MPSMIN) and is reported as a power of two.

The 'mdts' nvme device parameter is specified as in the spec, but the
'zoned.append_size_limit' parameter is specified in bytes. This is
suboptimal for a number of reasons:

  1. It is just plain confusing wrt. the definition of mdts.
  2. There is a lot of complexity involved in validating the value; it
     must be a power of two, it should be larger than 4k, if it is zero
     we set it internally to mdts, but still report it as zero.
  3. While "hw/block/nvme: improve invalid zasl value reporting"
     slightly improved the handling of the parameter, the validation is
     still wrong; it does not depend on CC.MPS, it depends on
     CAP.MPSMIN. And we are not even checking that it is actually less
     than or equal to MDTS, which is kinda the *one* condition it must
     satisfy.

Fix this by defining zasl exactly like mdts and checking the one thing
that it must satisfy (that it is less than or equal to mdts). Also,
change the default value from 128KiB to 0 (aka, whatever mdts is).

Klaus Jensen (3):
  hw/block/nvme: document 'mdts' nvme device parameter
  hw/block/nvme: deduplicate bad mdts trace event
  hw/block/nvme: align zoned.zasl with mdts

 hw/block/nvme.h       |  4 +--
 hw/block/nvme.c       | 67 ++++++++++++++-----------------------------
 hw/block/trace-events |  4 +--
 3 files changed, 25 insertions(+), 50 deletions(-)

-- 
2.30.1



             reply	other threads:[~2021-02-22 20:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 20:29 Klaus Jensen [this message]
2021-02-22 20:29 ` [PATCH 1/3] hw/block/nvme: document 'mdts' nvme device parameter Klaus Jensen
2021-02-22 20:29 ` [PATCH 2/3] hw/block/nvme: deduplicate bad mdts trace event Klaus Jensen
2021-02-22 20:29 ` [PATCH 3/3] hw/block/nvme: align zoned.zasl with mdts Klaus Jensen
2021-02-22 21:00 ` [PATCH 0/3] hw/block/nvme: mdts/zasl cleanup Keith Busch
2021-02-25 10:43   ` Klaus Jensen

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=20210222202921.92774-1-its@irrelevant.dk \
    --to=its@irrelevant.dk \
    --cc=k.jensen@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.