[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 3/3] hw/block/nvme: end-to-end data protection
From: |
Keith Busch |
Subject: |
Re: [PATCH RFC 3/3] hw/block/nvme: end-to-end data protection |
Date: |
Sat, 19 Dec 2020 03:08:06 +0900 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
On Thu, Dec 17, 2020 at 10:02:22PM +0100, Klaus Jensen wrote:
> static uint16_t nvme_rw(NvmeCtrl *n, NvmeRequest *req)
> {
> NvmeRwCmd *rw = (NvmeRwCmd *)&req->cmd;
> NvmeNamespace *ns = req->ns;
> uint32_t nlb = (uint32_t)le16_to_cpu(rw->nlb) + 1;
> uint64_t slba = le64_to_cpu(rw->slba);
> + uint16_t ctrl = le16_to_cpu(rw->control);
>
> uint64_t data_size = nvme_l2b(ns, nlb);
> + uint64_t real_data_size = data_size;
> uint64_t data_offset = nvme_l2b(ns, slba);
> enum BlockAcctType acct = req->cmd.opcode == NVME_CMD_WRITE ?
> BLOCK_ACCT_WRITE : BLOCK_ACCT_READ;
Since this is right in the middle of the nvme read/write path, and we
have the outstanding ZNS stuff intermixed here, could we possibly
converge on the ZNS solution first, and rebase new IO path capabilities
on a ZNS enabled tree?