[PATCH v4 01/20] nvme-tcp-offload: Add nvme-tcp-offload - NVMeTCP HW offload ULP
Shai Malin
malin1024 at gmail.com
Mon Jul 5 08:09:58 PDT 2021
On Thu, 1 Jul 2021 at 16:34, Christoph Hellwig <hch at lst.de> wrote:
>
> > +/* Kernel includes */
>
>
> > +/* Driver includes */
>
> I think these comments are a little pointless.
Will be removed.
>
> > +int nvme_tcp_ofld_register_dev(struct nvme_tcp_ofld_dev *dev)
>
> Can you spell out offload everywhere?
Sure.
>
> > +int nvme_tcp_ofld_report_queue_err(struct nvme_tcp_ofld_queue *queue)
> > +{
> > + /* Placeholder - invoke error recovery flow */
> > +
> > + return 0;
> > +}
>
> Please don't add any placeholders like this. The whole file is
> still pretty small with all the patches applied, so no need to split it.
Sure.
>
> > +static struct nvmf_transport_ops nvme_tcp_ofld_transport = {
> > + .name = "tcp_offload",
> > + .module = THIS_MODULE,
> > + .required_opts = NVMF_OPT_TRADDR,
> > + .allowed_opts = NVMF_OPT_TRSVCID | NVMF_OPT_NR_WRITE_QUEUES |
> > + NVMF_OPT_HOST_TRADDR | NVMF_OPT_CTRL_LOSS_TMO |
> > + NVMF_OPT_RECONNECT_DELAY | NVMF_OPT_HDR_DIGEST |
> > + NVMF_OPT_DATA_DIGEST | NVMF_OPT_NR_POLL_QUEUES |
> > + NVMF_OPT_TOS | NVMF_OPT_HOST_IFACE,
> > +};
> > +
> > +static int __init nvme_tcp_ofld_init_module(void)
> > +{
> > + nvmf_register_transport(&nvme_tcp_ofld_transport);
> > +
> > + return 0;
> > +}
> > +
> > +static void __exit nvme_tcp_ofld_cleanup_module(void)
> > +{
> > + nvmf_unregister_transport(&nvme_tcp_ofld_transport);
> > +}
>
> Looking at the final result this doesn't do much. Assuming we want
> to support these kinds of whacky offloads (which I'd rather not do),
> the proper way would be to allow registering multiple transport_ops
> structures for a given name rather adding an indirection that duplicates
> a whole lot of code.
In that case, would you prefer that we invoke the tcp-offload from
within the tcp flow?
Should it be with the same transport name (“tcp”) or with a different
transport name (“tcp_offload”)?
Also, would you prefer that we register the offload device driver
directly to blk_mq layer or through the tcp-offload layer?
>
> > + /* Offload device specific driver context */
> > + int num_hw_vectors;
> > +};
>
> As far as I can tell this is about queues, not "vectors" of some kind.
It's the num irqs which the device support. We can rename it "num_hw_queues".
>
> > +struct nvme_tcp_ofld_req {
> > + struct nvme_request req;
> > + struct nvme_command nvme_cmd;
> > + struct list_head queue_entry;
> > + struct nvme_tcp_ofld_queue *queue;
> > +
> > + /* Offload device specific driver context */
> > + void *private_data;
> > +
> > + /* async flag is used to distinguish between async and IO flow
> > + * in common send_req() of nvme_tcp_ofld_ops.
> > + */
> > + bool async;
> > +
> > + void (*done)(struct nvme_tcp_ofld_req *req,
> > + union nvme_result *result,
> > + __le16 status);
>
> This always points to nvme_tcp_ofld_req_done, why the costly indirection?
Will be fixed.
>
> > + /* Error callback function */
> > + int (*report_err)(struct nvme_tcp_ofld_queue *queue);
> > +};
>
> This seems to always point to nvme_tcp_ofld_report_queue_err, why the
> indirection?
Will be fixed.
More information about the Linux-nvme
mailing list