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

[Jiri Pirko <jiri@resnulli.us>]

Wed, Dec 20, 2017 at 09:28:03AM CET, borisp@mellanox.com wrote:
>
>> 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:
>> >Mon, Dec 18, 2017 at 12:10:27PM CET, ilyal@mellanox.com wrote:
>> >>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
>> >>hub.com%2FMellanox%2Ftls-
>> offload%2Ftree%2Ftls_device_v3&data=02%7C01%7
>> >>Cborisp%40mellanox.com%7C5aebe81262554f40221908d546cb7c37%7Ca6
>> 52971c7d
>> >>2e4d9ba6a4d149256f461b%7C0%7C0%7C636492762141202894&sdata=gYY
>> DEmspNfBs
>> >>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?
>
>