On 15 February 2017 at 04:32, ice <odp_d...@163.com> wrote: > HI： > > I am from a network security company in China, We intend to use odp to > complete a bottom forwarding engine and data channel. > What I am concerned about before is that in the case of multithreading, the > crash of the thread will hang all threads of the engine. > > I have a few questions want to ask you： > > 1. I see that there are several functions in the helper/linux.c, such as: > odph_linux_process_fork() and odph_linux_process_fork_n(), > But as you said. the process support is not really being pushed and is > faultly. And all the code used in the example is a multithreaded > architecture. > So odp support for multi-process architecture is not perfect, and is not > fully tested?
ODP is first an open API definition. Anyone can do an ODP implementation on its the hardware of his choice. Today, companies like cavium, Kallray, among others, develop their own product according to the ODP specification. The creation of a "concurrent execution environment" (we call them -sadly- "ODP threads", even if I'd personally prefer the choice of "ODP tasks" as they would be processes or threads in most cases) is not, as of today, part of ODP: It is the OS business. But a given ODP implementation may say it needs "ODP threads" to be of a specific nature (i.e.: they have to be pthreads, or they have to be processes, or anything else). Most implementation I have heard of wants ODP threads to be linux pthreads. Linaro also provides two specific ODP API implementations for linux, which we call "odp-linux-generic" and "odp-dpdk". Both work works with ODPthreads being pthreads. Besides the "linux-generic" implementation claims to support ODP threads being linux processes (and even a mix of pthreads and processes). I am not sure about what odp-dpdk claims to support. But I know for a fact that some functionality both will break if linux processes are used. I have fixed the issue for some part, but some other problems remains. There has been relatively low interrest for these issues, som far. If you need process support, make your voice heard! write to the list, join the public calls, contribute, or join Linaro! The "odph_linux_process_fork*" familly of functions are just wrappers around linux fork. nothing else. The equivalent set of functions exists for pthreads.There is no requirements to use them, even when using ODP. In my humble opinion, the presence of these function in the helpers is confusing... and is being discussed. If you feel more confident using pthread_create() and fork() directely, you should keep doing so. The odph_odpthreads_create() set of function, however, may be of more interest: They abstract the ODP thread concept: they will create whatever the ODP implementation wants as an ODPthread. For odp-linux-generic, either pthreads or processes, depending on a flag (as linux-generic claims to support both): This may be of interest for those who wish to develop applications which would work regardless of the choices which are made for an ODP thread implementation: Using these functions will help writing a more mortable ODP app (which would work on any ODP implementations even if the latter made different choices regarding the nature of an "ODP thread".) > 2. If we use a multithreaded architecture, if one of the threads crashes, > how does the stability of other threads guarantee? pthreads are pthreads. No difference with ODP. They are plain linux things: they share memory, file descriptors... So statbility is what you would expect with them regardless of ODP. > 3. If I want to transmit buffer from appA to appB and appC, Can I use odp's > schedule module to implement it? Or I can only use shm ipc to achieve it? > If I can use odp schedule to achieve, then how the performance? If appA, appB, appC are ODPthreads belonging to the same ODP instance, yes, you can transfer buffers between them. Support for multi instances (many ODP in the same machine) varies from ODP implementation to ODP implementation, and communication between different ODP instances is more limited today (but is being worked on). Performance will depends on the chosen ODP implementation and HW, of course. > 4. If I use odp to transfer data between a variety of app, the performance > will be how? not sure how this question differs from the previous one (3) > > Do you know the open event machine? What do you think of it and odp > contrast? I don't know much about the open event machine: My understanding was that is was targetting embeded systems only (mostly bare-metal). If this assumption is true, ODP is more general as it targets both embedded systems and the VM world. But my knowledge of the open event machine is too weak to comment more :-) Maybe some other on the list have comments, there. Regards, Christophe. > > thank you! > > > > > > > At 2017-02-14 22:12:06, "Christophe Milard" <christophe.mil...@linaro.org> > wrote: >>Hi, >> >>I am not sure about who you are, what you are trying to do, and how >>you are trying to do it. I am not even sure I understand fully your >>concerns. >> >>ODP itself does not specify what concurrency model is used. Some ODP >>implementations may use pthreads, some others processes, or whatever >>they want. >>Having said that, I feel most implementation use pthread, as you said. >>The linux-generic implementation provided by linaro actually claims to >>be supporting poth pthreads and processes. Saddly the process support >>is not really being pushed and is faultly (despite my effort to push >>it for a while). >> >>But as It claims to support it, you are welcome to file a bug, or even >>better contribute to fix that. >> >>Hope that helps, >> >>Christophe >> >>On 14 February 2017 at 07:26, ice <odp_d...@163.com> wrote: >>> >>> >>> I am trying to apply odp to our project, >>> >>> >>> But I found odp is a multi-threaded model . >>> >>> >>> So I began to worry about the stability of the work-thread, >>> >>> >>> If a thread crashes, what happens to other threads? >>> >>> >>> Why do not odp use a multi-process model? >>> >>> >>> Who can answer my question? >>> >>> >>> thanks > > > >
