Hi Dmitri, Pls see inline..
Regards, Bala On 7 February 2017 at 16:46, Dmitri Epshtein <d...@marvell.com> wrote: > Hi Bala, > > See inline > > Thanks > Dima > > -----Original Message----- > From: Bala Manoharan [mailto:bala.manoha...@linaro.org] > Sent: Tuesday, February 07, 2017 10:30 AM > To: Dmitri Epshtein > Cc: lng-odp-forward; Nir Erez > Subject: Re: [lng-odp] [EXT] Re: ODP crypto support with HW offload > > 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. > > [dima] Our HW doesn't support scheduler. > "odp_queue_dequeue" get crypto results from ODP (SW) queue. > > But when HW offload is used odp_crypto should get results from HW queue (when > ready) and enqueue the results to odp crypto completion queue. > We did it in odp_crypto_operation() function, but for few last requests that > were not ready yet during last odp_crypto_operation() call, > no one can check HW queue and move results from HW queue to completion queue > at least if we don't want to use timers or separate thread. > There is the reason for odp_crypto_operation_poll(void) function. > > I will be glad if you can suggest better way to do such functionality without > using multiple threads. odp_queue_t is a virtual concept in ODP, so would it be possible in your HW to map the completion queue to your HW queue directly so that when application calls odp_queue_deq() you could directly check the packets in HW queue instead of mapping between HW queue and compl queue ( i.e compl queue could be the direct HW queue or dequeue operation on completion queue could check for packets in HW queue(s) if there are more than one HW queue mapped to a single completion queue and return the packet ) We do have the concept of service core which could be dedicated to the application, you could run this operation in your service core. > > > 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./ >>>> >>>
