[<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