[PATCH V3 6/6] crypto/nx: Add P9 NX support for 842 compression engine
Dan Streetman
ddstreet at ieee.org
Thu Aug 31 23:31:35 AEST 2017
On Tue, Aug 29, 2017 at 5:54 PM, Haren Myneni <haren at linux.vnet.ibm.com> wrote:
> On 08/29/2017 02:23 PM, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-08-29 at 09:58 -0400, Dan Streetman wrote:
>>>> +
>>>> + ret = -EINVAL;
>>>> + if (coproc && coproc->vas.rxwin) {
>>>> + wmem->txwin = nx842_alloc_txwin(coproc);
>>>
>>> this is wrong. the workmem is scratch memory that's valid only for
>>> the duration of a single operation.
>
> Correct, workmem is used until crypto_free is called.
that's not a 'single operation'. a single operation is compress() or
decompress().
>>>
>>> do you actually need a txwin per crypto transform? or do you need a
>>> txwin per coprocessor? or txwin per processor? either per-coproc or
>>> per-cpu should be created at driver init and held separately
>>> (globally) instead of a per-transform txwin. I really don't see why
>>> you would need a txwin per transform, because the coproc should not
>>> care how many different transforms there are.
>>
>> We should only need a single window for the whole kernel really, plus
>> one per user process who wants direct access but that's not relevant
>> here.
>
> Opening send window for each crypto transform (crypto_alloc,
> compression/decompression, ..., crypto_free) so that does not
> have to wait for the previous copy/paste complete.
> VAS will map send and receive windows, and can cache in send
> windows (up to 128). So I thought using the same send window
> (per chip) for more requests (say 1000) may be adding overhead.
>
> I will make changes if you prefer using 1 send window per chip.
i don't have the spec, so i shouldn't be making the decision on it,
but i do know putting a persistent field into the workmem is the wrong
location. If it's valid for the life of the transform, put it into
the transform context. The workmem buffer is intended to be used only
during a single operation - it's "working memory" to perform each
individual crypto transformation.
>
>>
>> Cheers,
>> Ben.
>>
>
More information about the Linuxppc-dev
mailing list