I favor finishing ODP (ex 2.0) integration rather than optimizing
linux-generic at this stage.

On 11 December 2017 at 14:39, Peltonen, Janne (Nokia - FI/Espoo) <
janne.pelto...@nokia.com> wrote:

> Hi,
>
> When playing with IPsec I noticed that the Linux generic
> ODP implementation creates a separate OpenSSL crypto context
> for each crypto-operation as opposed to doing it at ODP
> crypto session creation. With IPsec this adds a lot of
> overhead for every packet processed and significantly
> reduces packet throughput.
>
> I wonder what, if anything, should be done about it.
>
> I already almost sent a patch to create and initialize
> crypto contexts only once per session but realized that
> it is not that easy.
>
> Here are some alternatives that came to my mind, but all
> of them have their own problems:
>
> a) Create per-thread OpenSSL contexts at crypto session
>    creation time.
>    - Does not work with ODP threads that do not share
>      their address space since OpenSSL is allocating
>      memory through malloc() during context creation.
>
> b) Do a) plus provide OpenSSL a custom memory allocator
>    on top of shared memory.
>    - There is no generic heap allocator in ODP code base.
>
> c) Create per-thread contexts lazily when needed.
>    - Creation would work as it would happen in the right
>      thread but there would be no way to delete the
>      contexts. The thread destroying the ODP crypto
>      session cannot delete the per-thread contexts that
>      might reside in a different address spaces. That
>      thread could ask every other thread to do the
>      per-thread cleanup, except that there is no mechanism
>      for that without application assistance or big
>      changes in the generic ODP code.
>
> d) Create a limited-size cache of per-thread contexts.
>    - This would allow postponing the deletion of each
>      context either to the point the cache slot needs
>      to be reused or all the way to ODP termination,
>      both occuring in the right thread. But this is
>      getting complicated and sizing the cache is nasty.
>
> Any thoughts?
>
>         Janne
>
>
>


-- 
[image: Linaro] <http://www.linaro.org/>
François-Frédéric Ozog | *Director Linaro Networking Group*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

Reply via email to