netdev - RE: [PATCH net-next RFC v1 05/10] nvme-tcp: Add DDP offload control path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <PH0PR18MB38459981C2CC78885426C456CCE80@PH0PR18MB3845.namprd18.prod.outlook.com>
Date:   Wed, 11 Nov 2020 05:43:01 +0000
From:   Shai Malin <smalin@...vell.com>
To:     "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "Sagi Grimberg" <sagi@...mberg.me>,
        Boris Pismenny <borispismenny@...il.com>,
        "Boris Pismenny" <borisp@...lanox.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "saeedm@...dia.com" <saeedm@...dia.com>, "hch@....de" <hch@....de>,
        "axboe@...com" <axboe@...com>,
        "kbusch@...nel.org" <kbusch@...nel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "edumazet@...gle.com" <edumazet@...gle.com>
CC:     Yoray Zack <yorayz@...lanox.com>, Ariel Elior <aelior@...vell.com>,
        "Ben Ben-Ishay" <benishay@...lanox.com>,
        Michal Kalderon <mkalderon@...vell.com>,
        "boris.pismenny@...il.com" <boris.pismenny@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Or Gerlitz <ogerlitz@...lanox.com>
Subject: RE: [PATCH net-next RFC v1 05/10] nvme-tcp: Add DDP offload control
 path


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.