Hi Alex, I just sent out a V2 of the RFC which shows how a synchronous only implementation could use the updated APIs to use memory instead of ODP buffers while the application is unaware. The idea is to allow the implementation to freely choose how it wants to implement completion events:
· completion event is the packet · completion event is a buffer but not the packet · completion event is simple memory area As to why it has to be abstracted, the application is by definition the entity that retrieves the buffer from the completion queue when operating asynchronously. I believe the API as I have it in the V2 version of the patch isolates that dependency down to the one API call “odp_crypto_compl_event_from_buffer”. Hope this helps clear up my intention. From: Alexandru Badicioiu [mailto:[email protected]] Sent: Wednesday, December 10, 2014 2:49 AM To: Robbie King (robking) Cc: [email protected] Subject: Re: [lng-odp] [RFC v1 0/3] Proposed crypto completion event implementation Hi Robbie, could you add a few words on the motivation for this patch? I think I'm a bit outdated with the new completion event requirements understanding. My understanding was that completion event is not something that needs to be abstracted as for the most HW entities, essentially is just a memory buffer where the implementation returns the output associated with a crypto operation request. It has to be a buffer and not a simple value because the output is always an aggregate - status/error codes, output data (packet), context, etc. In addition, it had to be an entity that can be delivered from an ODP queue, so this is why it has been defined as an odp_buffer_t. In my view its meaning was exactly like a memory buffer for a regular (POSIX) read/aio_read operation - the application is responsible to provide it and it's not an issue if the input packet buffer itself is used explicitly as long as the implementation can handle it. Thanks, Alex On 10 December 2014 at 06:04, Robbie King <[email protected]<mailto:[email protected]>> wrote: v1 - Illustrates abstracting completion event out to be a unique data type. What is here still uses packet to serve as completion event however application is no longer aware of the fact and simply converts the received buffer to a completion context and uses accessor functions from there on out. Subsequent version of patch will (hopefully) demonstrate how a synchronous only implementation can be achieved relatively effeciently using the same API. Robbie King (3): Add completion event updates to odp_crypto.h Add completion event updates to implementation Update IPsec example app to use new completion event constructs example/ipsec/odp_ipsec.c | 68 +++++++++++++++------- platform/linux-generic/include/api/odp_crypto.h | 56 +++++++++++++----- .../linux-generic/include/odp_crypto_internal.h | 1 + platform/linux-generic/odp_crypto.c | 60 +++++++++++++------ 4 files changed, 131 insertions(+), 54 deletions(-) -- 1.9.1 _______________________________________________ lng-odp mailing list [email protected]<mailto:[email protected]> http://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
