[PATCH 1/2] nvme: support fused nvme requests

Clay Mayers klayph at gmail.com
Wed Jan 6 10:01:09 EST 2021


Thanks for the very fast feedback.  I will ensure this is pci only for now.

On Tue, Jan 5, 2021 at 4:35 PM James Smart <james.smart at broadcom.com> wrote:
>
>
>
> On 1/5/2021 2:49 PM, klayph at gmail.com wrote:
> > From
>
> >
> >   /*
> > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > index 3be352403839..c24729e100bc 100644
> > --- a/drivers/nvme/host/pci.c
> > +++ b/drivers/nvme/host/pci.c
> > @@ -491,6 +491,30 @@ static inline void nvme_write_sq_db(struct nvme_queue *nvmeq, bool write_sq)
> >       nvmeq->last_sq_tail = nvmeq->sq_tail;
> >   }
> >
> > +/**
> > + * nvme_submit_cmd2() - Copy fused commands into a queue and ring the doorbell
> > + * @nvmeq: The queue to use
> > + * @cmd: The first command to send
> > + * @cmd2: the second command to send
> > + * @write_sq: whether to write to the SQ doorbell
> > + */
> > +static void nvme_submit_cmd2(struct nvme_queue *nvmeq, struct nvme_command *cmd,
> > +                          struct nvme_command *cmd2, bool write_sq)
> > +{
> > +     spin_lock(&nvmeq->sq_lock);
> > +     memcpy(nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes),
> > +             cmd, sizeof(*cmd));
> > +     if (++nvmeq->sq_tail == nvmeq->q_depth)
> > +             nvmeq->sq_tail = 0;
> > +     memcpy(nvmeq->sq_cmds + (nvmeq->sq_tail << nvmeq->sqes),
> > +             cmd2, sizeof(*cmd2));
> > +     if (++nvmeq->sq_tail == nvmeq->q_depth)
> > +             nvmeq->sq_tail = 0;
> > +     nvme_write_sq_db(nvmeq, write_sq);
> > +     spin_unlock(&nvmeq->sq_lock);
> > +}
> > +
> > +
> >   /**
> >    * nvme_submit_cmd() - Copy a command into a queue and ring the doorbell
> >    * @nvmeq: The queue to use
> > @@ -918,7 +942,13 @@ static blk_status_t nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
> >       }
> >
> >       blk_mq_start_request(req);
> > -     nvme_submit_cmd(nvmeq, &cmnd, bd->last);
> > +
> > +     if (cmnd.common.flags & NVME_CMD_FUSE_FIRST)
> > +             memcpy(&nvme_req(req)->nrq2->cmnd, &cmnd, sizeof(cmnd));
> > +     else if (cmnd.common.flags & NVME_CMD_FUSE_SECOND)
> > +             nvme_submit_cmd2(nvmeq, &nvme_req(req)->cmnd, &cmnd, bd->last);
> > +     else
> > +             nvme_submit_cmd(nvmeq, &cmnd, bd->last);
> >       return BLK_STS_OK;
> >   out_unmap_data:
> >       nvme_unmap_data(dev, req);
>
> I think Keith caught the most concerning issue. I've been thinking of
> others but they mostly seem to work.  I assume recopies of the first
> fused cmd to the data structure don't hurt.  I would expect there to be
> a couple of other odd issues if the two requests start working
> independently.
>
> This is the pci transport only. You should either put something in to
> not allow the ioctl on a non-pci transport, or add the support (or
> rejection) to the fabric transports as well.
>
> -- james
>
>
>
>
> --
> This electronic communication and the information and any files transmitted
> with it, or attached to it, are confidential and are intended solely for
> the use of the individual or entity to whom it is addressed and may contain
> information that is confidential, legally privileged, protected by privacy
> laws, or otherwise restricted from disclosure to anyone else. If you are
> not the intended recipient or the person responsible for delivering the
> e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.



More information about the Linux-nvme mailing list