Regards, Bala
On 6 February 2017 at 18:08, Dmitri Epshtein <d...@marvell.com> wrote: > Hi, > > There are two issues in current odp_crypto APIs (file > $ODP_DIR/include/odp/api/spec/crypto.h) > > 1. No support batch/burst for crypto operations > 2. No support crypto results polling by application in case of ASYNC > mode with HW offload support > > These issues became important for performance when high throughput HW engine > is used for crypto operation offload. > > My suggestion is to add functionality above by very small changes in crypto > APIs. > > To solve issue (1) I suggest to add two extra parameters to > odp_crypro_operation() API (see below) > /** > * Crypto per packet operation > * > * Performs the cryptographic operations specified during session creation > * on the packet. If the operation is performed synchronously, "posted" > * will return FALSE and the result of the operation is immediately available. > * If "posted" returns TRUE the result will be delivered via the completion > * queue specified when the session was created. > * > * @param params Array of operation parameters. > * @param op_num (in/out) In: Pointer to number of operations in “params” > array. > * Out: Pointer to number of posted operations. > * @param posted Pointer to return posted, TRUE for async operation > * @param results Array of operation results (when posted returns > FALSE) > * @param res_num (in/out): In: Pointer to number of results in “results” > array > Out: Pointer to number of ready results in > SYNC mode. > > * > * @retval 0 on success > * @retval <0 on failure > */ > int odp_crypto_operation(odp_crypto_op_params_t *params, int *op_num, > odp_bool_t *posted, > odp_crypto_op_result_t *results, int *res_num); > > > To solve issue (2) I suggest to add new crypto API (see below) > > /** > * Poll the cryptographic operations results > * > * This function is relevant only for async mode. > * It should be called if no more data to call odp_crypto_operation(), > * but not all results are received. > */ > int odp_crypto_operation_poll(void); Not sure about the exact use-case for odp_crypto_operation_poll() function but We do have an existing odp_queue_deq() function and would'nt it solve your scenario by calling the dequeue function on the compl queue? or if your HW supports a scheduler then the same would be solved by odp_schedule() call. Regards, Bala > > > Thanks > Dima > > -----Original Message----- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Wednesday, January 18, 2017 6:21 PM > To: Maxim Uvarov; lng-odp-forward > Cc: Dmitri Epshtein; Nir Erez > Subject: [EXT] Re: ODP crypto support with HW offload > > External Email > > ---------------------------------------------------------------------- > +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./ >>> >>
