qemu-devel
[Top][All Lists]
Advanced

[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: Klaus Jensen
Subject: Re: [PATCH RFC 3/3] hw/block/nvme: end-to-end data protection
Date: Fri, 18 Dec 2020 19:24:58 +0100
User-agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396


On Fri, Dec 18, 2020, at 19:08, Keith Busch wrote:
> 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?
>

Yes, absolutely. We marked this RFC to get some discussion going and we got 
that :)

Will definitely merge zns first :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]