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] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM4PR0501MB27231C4EC47FB287D7FF1EC0D40C0@AM4PR0501MB2723.eurprd05.prod.outlook.com>
Date:   Wed, 20 Dec 2017 16:23:03 +0000
From:   Ilya Lesokhin <ilyal@...lanox.com>
To:     David Miller <davem@...emloft.net>,
        Boris Pismenny <borisp@...lanox.com>
CC:     "jiri@...nulli.us" <jiri@...nulli.us>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davejwatson@...com" <davejwatson@...com>,
        "tom@...bertland.com" <tom@...bertland.com>,
        "hannes@...essinduktion.org" <hannes@...essinduktion.org>,
        Aviad Yehezkel <aviadye@...lanox.com>,
        "Liran Liss" <liranl@...lanox.com>
Subject: RE: [PATCH v3 net-next 0/6] tls: Add generic NIC offload
 infrastructure

> 
> > Dave, would you prefer to get the driver patches that use this infra
> > before the infra?
> 
> The arguments you present are silly.
> 
> In order to analyze any proposed API, the users of it must be presented for the
> reviewers to see as well.
> 
> Logically, you must have tried to make use of the APIs to see how well they
> work and are usable for at least one such user, right?
Right, we agree.
> 
> Therefore, the use case exists, and you must present it alongside the API
> proposal.
> 
> Whether you provide the API addition patches and the user in the same patch
> series, or a separate one, doesn't really matter.  What is important is that this
> is accessible to the reviewer at the same time.

Note that we did provide a user in an accessible place.
https://github.com/Mellanox/tls-offload/tree/tls_device_v3
The link was at the bottom of the cover letter.

We just feel that the code there is not yet ready for upstream submission, and it might have
conflicts with other stuff submitted by Mellanox.

Would it be better if we submitted the mlx5e TLS support as an RFC alongside the TLS
Infrastructure patches?



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ