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]> 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] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
