[PATCH v4 01/20] nvme-tcp-offload: Add nvme-tcp-offload - NVMeTCP HW offload ULP

[Prabhakar Kushwaha]

Hi Christoph,

On Mon, Jul 5, 2021 at 8:40 PM Shai Malin <malin1024 at gmail.com> wrote:
>
> On Thu, 1 Jul 2021 at 16:34, Christoph Hellwig <hch at lst.de> wrote:
> >

[snip]

>
> >
> > > +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?
>

I hope you got some time to look into the above queries.
We would appreciate your feedback in order to finalize the design.

--pk