On 16 February 2017 at 13:31, Dmitri Epshtein <[email protected]> wrote: > Hello, > > As part of action items from previous meeting I am going to suggest crypto > APIs with burst support. > > But before I would like to confirm my understanding of existing > odp_crypto_operation() API definition > > int odp_crypto_operation(odp_crypto_op_params_t *param, > odp_bool_t *posted, > odp_crypto_op_result_t *result); > > 1. Decision about sync/async mode of operation done accordingly with > algorithm: > a. If (compl_queue == NULL) for the session and (result != NULL) > operation MUST be done synchronously > b. if (compl_queue != NULL) for the session and (result == NULL) > operation MUST be done asynchronously > c. if (compl_queue == NULL) for the session and (result == NULL) > operation MUST failed > d. if (compl_queue != NULL) for the session and (result != NULL) > operation can be done synchronously or asynchronously accordingly > implementation decision on per operation base.
I would prefer sync or async mode of operation done based on the settings done explicitly by the application rather than having this permutations with compl_queue and result. > > 2. Operations must be processed "in order" for each session, but operations > of different sessions can be processed out of order. > > Am I correct about my understanding above? Yes Regards, Bala > > > Thanks > Dmitri > > -----Original Message----- > From: Mike Holmes [mailto:[email protected]] > Sent: Monday, February 06, 2017 8:56 PM > To: Dmitri Epshtein > Cc: lng-odp-forward; Nir Erez > Subject: Re: [lng-odp] [EXT] Re: ODP crypto support with HW offload > > Dmitri, can you make the public call tomorrow ? > > I added this speculativly to the agenda > https://collaborate.linaro.org/display/ODP/2017-02-07+ODP+ARCH > > On 6 February 2017 at 07:38, Dmitri Epshtein <[email protected]> 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); >> >> >> Thanks >> Dima >> >> -----Original Message----- >> From: Bill Fischofer [mailto:[email protected]] >> 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 <[email protected]> >> 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 - [email protected] <mailto:[email protected]> >>>> 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./ >>>> >>> > > > > -- > Mike Holmes > Program Manager - Linaro Networking Group > Linaro.org │ Open source software for ARM SoCs > "Work should be fun and collaborative, the rest follows"
