On 12/05/2014 04:16 PM, Alexandru Badicioiu wrote:
Hi ,
what this patch wants to accomplish can be done with the actual API this
way : if the implementation really cannot reuse the input packet as the
completion event (are there implementations which cannot?) it can return
an error and the application could allocate a separate completion event:
There is a little overhead with the first assignment and with the failed
crypto operation in case of platforms which do not support reusing the
packet but the API doesn't need to be modified (only adding a new error
code).

odp_buffer_t compl = odp_packet_to_buffer(op_params.pkt);
rc = odp_crypto_operation(&op_params, &posted, compl);
if (odp_unlikely(ODP_CRYPTO_INVALID_COMPL_EVENT == rc)) {
       compl = odp_buffer_alloc();
       rc = odp_crypto_operation(&op_params, &posted, compl);
}

This approach really looks like a hack and it has several issues:

1. Application have to remember to free completion in case it was
   allocated. In asynchronous case completion event may be dequeued
   in another thread, so 'need to be freed' information should be
   passed somehow along with the completion event. Implementation is in
   much better position to handle this case.

2. Implicitly passing packet as a completion event may mislead
   application developer, because he may assume that he will get it back
   in exactly the same state (that's exactly what happened in our IPsec
   application). But accordingly to the specification completion event
   is an opaque token, so developer should not assume that its state is
   preserved. Instead we have accessors functions to get information
   from the completion event.

_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to