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?