+cc ODP mailing list. These sort of discussions belong on the mailing
list as that's where those most knowledgeable and impacted by API
changes will see it.
ODP implementations are free to batch/burst individual
odp_crypto_operation() calls but extensions to support application
configuration of this sort of behavior would seem reasonable. Please
put together an RFC on this and we can discuss it.
Note that our crypto focus, as Maxim mentioned, is currently concerned
with higher-level protocols like IPsec as well as defining an API
framework to support full offload of these protocols such that
applications need not be directly involved in the operational aspects
of such processing.
If you are able to attend BUD17 we'll be discussing these topics and
more in our face to face meetings.
On Wed, Jan 18, 2017 at 7:48 AM, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> Hello Dmitri,
>
> I CC Bill but I think it's better to send this email to odp mailing list.
>
> On 01/18/17 16:07, Dmitri Epshtein wrote:
>> Hi Maxim,
>>
>>
>>
>> I am Dmitri Epshtein from Marvell Israel. We were meeting on last Linaro
>> Connect conference in Las Vegas.
>>
>
> Yes, I remember. Are you planning to go to our next Connect in Budapest?
>
>>
>>
>> I would like to discuss with you ODP crypto support with HW engine
>> offload for better understanding existing APIs and
>>
>> to know what are next steps planned by Linaro ODP community in this
>> direction.
>>
>>
>
> One of big goal is IP sec protocol offload.
>
>
>>
>> Our SoC as I assume most others chips from different vendors has Fast HW
>> crypto engine inside.
>>
>> It means application can enqueue crypto operation request for HW
>> processing and can continue to work until HW will finish request processing.
>>
>>
>>
>> Currently existing crypto APIs has single API to contact HW:
>>
>>
>>
>> intodp_crypto_operation(odp_crypto_op_params_t *params,
>>
>> odp_bool_t *posted,
>>
>> odp_crypto_op_result_t *result);
>>
>>
>>
>> Typical crypto application e.g. odp_ipsec.c working in ASYNC mode call
>> odp_crypto_operation() and continue to next event.
>>
>> In “async” mode application expect that finished crypto results will be
>> pushed to comp_queue.
>>
>>
>>
>> But somebody should trigger read finished crypto results from HW and
>> push them to comp_queue.
>>
>> It can be done internally by odp_crypto.c implementation (by other
>> thread) or as side effect of next crypto_operations.
>>
>>
>>
>> I would like to have other API that application can call to trigger sync
>> results operation by HW.
>>
>> e.g. intodp_crypto_result_sync()
>>
>
> You can refer to that test:
> ./test/common_plat/validation/api/crypto/odp_crypto_test_inp.c
>
> ./include/odp/api/spec/crypto.h
> /**
> * Crypto API operation mode
> */
> typedef enum {
> /** Synchronous, return results immediately */
> ODP_CRYPTO_SYNC,
> /** Asynchronous, return results via posted event */
> ODP_CRYPTO_ASYNC,
> } odp_crypto_op_mode_t;
>
> So depending on initialization parameters you specify sync or async mode
> is used.
> odp_crypto_operation() is common for both cases.
>
>>
>>
>> Other functionality is missing currently in crypto APIs is burst support.
>>
>> There is significant performance improvement if crypto operations are
>> submitted to HW in bursts.
>>
>>
>>
>> Maybe possible option to improve crypto APIs to do them similar to pktio
>> APIs with set of functions per IO, e.g. enq/deq or send/recv
>>
>>
>>
>> What do you thinks about that?
>>
>
> I think that is good api proposal. Bill looks like it's reasonable to
> discuss that on next call.
>
>
>
>>
>>
>> Can you recommend me ODP preferred way to process crypto HW offload?
>>
>
> I think both ways async and sync. In general odp validation tests have
> to pass.
>
>> Can you point me to next steps in ODP crypto APIs development?
>>
>
> Looks at what we have in api-next branch and mailing list discussion. On
> Tuesdays we have meeting call which is open for everybody feel free to
> join and ask any questions. But in general as I said people work on
> ipsec protocol offload.
>
> Thank you,
> Maxim.
>
>
>>
>>
>> /Thanks/
>>
>> /Dima/
>>
>>
>>
>> /Dmitri Epshtein - Software engineer/
>> /Marvell Semiconductor Israel Ltd
>> 6 Hamada Street
>> Mordot HaCarmel Industrial Park
>> Yokneam 20692, ISRAEL/
>> /Email - d...@marvell.com <mailto:d...@marvell.com>
>> Tel - + 972 4 9091455 /
>> /Fax - + 972 4 9091501/
>> /WWW Page: http://www.marvell.com
>>
>> This message may contain confidential, proprietary or legally privileged
>> information. The information is intended only for the use of the
>> individual or entity named above. If the reader of this message is not the
>> intended recipient, you are hereby notified that any dissemination,
>> distribution or copying of this communication is strictly prohibited. If
>> you have received this communication in error, please notify us
>> immediately by telephone, or by e-mail and delete the message from your
>> computer./
>>
>
