Wed, Dec 20, 2017 at 09:28:03AM CET, bor...@mellanox.com wrote: > >> Tue, Dec 19, 2017 at 01:10:10AM CET, j...@resnulli.us wrote: >> >> Mon, Dec 18, 2017 at 06:10:10PM CET, j...@resnulli.us wrote: >> >Mon, Dec 18, 2017 at 12:10:27PM CET, il...@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? > >
