On 11/10/2020 1:24 AM, Sagi Grimberg wrote:
> >>> diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> >>> index
> >>> 8f4f29f18b8c..06711ac095f2 100644
> >>> --- a/drivers/nvme/host/tcp.c
> >>> +++ b/drivers/nvme/host/tcp.c
> >>> @@ -62,6 +62,7 @@ enum nvme_tcp_queue_flags {
> >>> NVME_TCP_Q_ALLOCATED = 0,
> >>> NVME_TCP_Q_LIVE = 1,
> >>> NVME_TCP_Q_POLLING = 2,
> >>> + NVME_TCP_Q_OFFLOADS = 3,
> >
> > Sagi - following our discussion and your suggestions regarding the
> > NVMeTCP Offload ULP module that we are working on at Marvell in
> > which a TCP_OFFLOAD transport type would be added,
>
> We still need to see how this pans out.. it's hard to predict if this
> is the best approach before seeing the code. I'd suggest to share some
> code so others can share their input.
>
We plan to do this soon.
> > we are concerned that perhaps the generic term "offload" for both
> > the
> transport type (for the Marvell work) and for the DDP and CRC offload
> queue (for the Mellanox work) may be misleading and confusing to
> developers and to users. Perhaps the naming should be "direct data
> placement", e.g.
> NVME_TCP_Q_DDP or NVME_TCP_Q_DIRECT?
>
> We can call this NVME_TCP_Q_DDP, no issues with that.
>
Great. Thanks.
