RE: [PATCH v3 net-next 6/6] tls: Add generic NIC offload infrastructure.

From: Ilya Lesokhin <ilyal@mellanox.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"davejwatson@fb.com" <davejwatson@fb.com>,
	"tom@herbertland.com" <tom@herbertland.com>,
	"hannes@stressinduktion.org" <hannes@stressinduktion.org>,
	Boris Pismenny <borisp@mellanox.com>,
	"Aviad Yehezkel" <aviadye@mellanox.com>,
	Liran Liss <liranl@mellanox.com>
Subject: RE: [PATCH v3 net-next 6/6] tls: Add generic NIC offload infrastructure.
Date: Tue, 19 Dec 2017 15:38:16 +0000	[thread overview]
Message-ID: <AM4PR0501MB272304FEA861384F0F7895BCD40F0@AM4PR0501MB2723.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20171219151138.GD6122@localhost.localdomain>

Tuesday, December 19, 2017 5:12 PM, Marcelo Ricardo Leitner wrote:

> > I'm not quite sure what you mean by "no net_device's are registered"
> > Presumably you mean there is no device that implements the
> > NETIF_F_HW_TLS_TX capability yet.
> 
> Not really. Let me try again. This patchset is using the expression "tls_device".
> When I read that, I expect a new interface type, like a tunnel, that would be
> created on top of another interface that has the offloading capability. That's
> why I'm confused. IMHO "tls_offload" is a better fit. Makes sense?
> 

We don't expose a new interface. An existing netdev does the offload.

The xfrm layer also calls the offload layer xfrm_device and It also doesn't need to
add another interface to offload ipsec to a netdev.

I thought about calling it tls_hw or tls_hw_offload.
The problem is that the important distinction here is that the 
offload is done by a netdev.
tls_sw can also use hw offload if you have the required 
memory to memory crypto engine and crypto_alloc_aead("gcm(aes)", 0, 0); 
decides on using it.