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

Wed, Dec 20, 2017 at 09:28:03AM CET, borisp@mellanox.com wrote:

quoted

Tue, Dec 19, 2017 at 01:10:10AM CET, jiri@resnulli.us wrote:

Mon, Dec 18, 2017 at 06:10:10PM CET, jiri@resnulli.us wrote:

quoted

Mon, Dec 18, 2017 at 12:10:27PM CET, ilyal@mellanox.com wrote:

quoted

Changes from v2:
- Fix sk use after free and possible netdev use after free
- tls device now keeps a refernce on the offloading netdev
- tls device registers to the netdev notifer.
 Upon a NETDEV_DOWN event, offload is stopped and
 the reference on the netdev is dropped.
- SW fallback support for skb->ip_summed != CHECKSUM_PARTIAL
- Merged TLS patches are no longer part of this series.

Changes from v1:
- Remove the binding of the socket to a specific netdev
 through sk->sk_bound_dev_if.
 Add a check in validate_xmit_skb to detect route changes
 and call SW fallback code to do the crypto in software.
- tls_get_record now returns the tls record sequence number.
 This is required to support connections with rcd_sn != iv.
- Bug fixes to the TLS code.

This patchset adds a generic infrastructure to offload TLS crypto to a
network devices.

patches 1-2 Export functions that we need patch 3 adds infrastructue
for offloaded socket fallback patches 4-5 add new NDOs and
capabilities.
patch 6 adds the TLS NIC offload infrastructure.

Github with mlx5e TLS offload support:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F

git

quoted

quoted

hub.com%2FMellanox%2Ftls-

offload%2Ftree%2Ftls_device_v3&data=02%7C01%7

quoted

quoted

Cborisp%40mellanox.com%7C5aebe81262554f40221908d546cb7c37%7Ca6

52971c7d

quoted

quoted

2e4d9ba6a4d149256f461b%7C0%7C0%7C636492762141202894&sdata=gYY

DEmspNfBs

quoted

quoted

aQhefcEojl456L9eWqZnEEI7iPCT0NA%3D&reserved=0

I don't get it. You are pushing infra but not the actual driver part
who is consuming the infra? Why?

Okay. Since the driver that uses the API introduced by this patchset is
missing, this patchset should be marked as RFC.

Dave, I see that you were about to apply v2. I'm sure you missed this.
Thanks.

Isn't this a chicken and egg problem, where something must come first,
driver or infra. Unless we combine the infra patches with mlx5 driver
code and submit both in a single pull request.

Yes, you should submit that in a single patchset. That is the usual way.
Thanks.

Here, we assumed that the infra goes first, and we will submit the
driver soon after. We could submit the driver first instead.

No. You cannot do that like this.

Dave, would you prefer to get the driver patches that use this infra before
the infra?