odp_init_global() allocates shm, then odp_init_local() / odp_term_local() allocates/destroys per thread contexts in array in that shm. I think that has to work.
Maxim. On 11 December 2017 at 17:02, Francois Ozog <francois.o...@linaro.org> wrote: > 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 >
