[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cf066030-2193-6b4f-05ae-afe7ead52ca7@chelsio.com>
Date: Tue, 23 Jan 2018 13:42:00 +0530
From: Atul Gupta <atul.gupta@...lsio.com>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: herbert@...dor.apana.org.au, linux-crypto@...r.kernel.org,
ganeshgr@...lsio.com, netdev@...r.kernel.org, davem@...emloft.net,
davejwatson@...com
Subject: Re: [RFC crypto v3 0/9] Chelsio Inline TLS
On Monday 22 January 2018 03:46 AM, Sabrina Dubroca wrote:
> 2017-12-20, 17:03:02 +0530, Atul Gupta wrote:
>> RFC series for Chelsio Inline TLS driver (chtls.ko)
>>
>> Driver use the ULP infrastructure to register chtls as Inline TLS ULP.
> I don't think drivers should be registering their own ULP. TLS
> offloading should be transparent to userspace, whatever HW ends up
> being used. If each driver implements its own ULP, the application has
> to be aware of what HW and what driver it's running on.
using different ULP is derived from
https://patchwork.kernel.org/patch/9746381/
> I think this offload should rely on a generic infrastructure, not
> build its own private interface. Look at the current kTLS code, the
> proposal for an offload infrastructure [0] from Mellanox, and see how
> you can fit your driver into that, and extend what's missing.
>
> [0] https://patchwork.ozlabs.org/patch/849984/
The driver indeed used the proposed offload infrastructure and extended
for Inline Rx/Tx
>
>
> [...]
>> Atul Gupta (9):
>> chtls: structure and macro definiton
>> cxgb4: Inline TLS FW Interface
>> cxgb4: LLD driver changes to enable TLS
>> chcr: Key Macro
>> chtls: Key program
>> chtls: CPL handler definition
>> chtls: Inline crypto request Tx/Rx
>> chtls: Register the ULP
>> Makefile Kconfig
> That patchset is split so that each patch touches a separate set of
> files, and the description of the contents of each patch is very
> limited. Can you try to group your changes by feature instead? That
> should help you come up with descriptive commit messages as well.
Made all attempts to group the contents based on functionality, the set
is broken into
driver registration, I/O with crypto Inline request, key handling and
messages exchanged with
hardware.
>
> Thanks,
>
Powered by blists - more mailing lists