Re: [lng-odp] thread/shmem discussion summary V4

On Thu, Jun 9, 2016 at 9:38 AM, Jerin Jacob wrote: > On Thu, Jun 09, 2016 at 03:20:23PM +0200, Christophe Milard wrote: > > Yes, we do have name lookup functions to get handles, but I cannot see > > what would make these the only way to retrieve handles from ODP.

Re: [lng-odp] thread/shmem discussion summary V4

to start with: Thanks Bill for taking the time to answer :-). I DO appreciate. The only thing I really want us to agree on is that your approach is really a handles-only approach (when communicating between odp threads), regardless of what a thread is. Because if we don't define the behaviour, in

Re: [lng-odp] thread/shmem discussion summary V4

On Thu, Jun 09, 2016 at 03:20:23PM +0200, Christophe Milard wrote: > Yes, we do have name lookup functions to get handles, but I cannot see > what would make these the only way to retrieve handles from ODP. > Why couldn't your first process send the handle to the second process > via another IPC,

Re: [lng-odp] thread/shmem discussion summary V4

On Thu, Jun 9, 2016 at 9:01 AM, Christophe Milard < christophe.mil...@linaro.org> wrote: > On 9 June 2016 at 14:30, Bill Fischofer wrote: > > > > > > On Thu, Jun 9, 2016 at 7:13 AM, Christophe Milard > > wrote: > >> > >> Bill: > >> S19:

Re: [lng-odp] thread/shmem discussion summary V4

On 9 June 2016 at 14:30, Bill Fischofer wrote: > > > On Thu, Jun 9, 2016 at 7:13 AM, Christophe Milard > wrote: >> >> Bill: >> S19: When you write:"These addresses are intended to be used within >> the scope of the calling thread and

Re: [lng-odp] thread/shmem discussion summary V4

Yes, we do have name lookup functions to get handles, but I cannot see what would make these the only way to retrieve handles from ODP. Why couldn't your first process send the handle to the second process via another IPC, e.g. unix sockets, signaling, message passing or even writing/reading to a

Re: [lng-odp] thread/shmem discussion summary V4

On Thu, Jun 09, 2016 at 02:13:49PM +0200, Christophe Milard wrote: > Bill: > S19: When you write:"These addresses are intended to be used within > the scope of the calling thread and should not be assumed to have any > validity outside of that context", do you really mean this, regardless > on how

Re: [lng-odp] thread/shmem discussion summary V4

On Thu, Jun 9, 2016 at 7:13 AM, Christophe Milard < christophe.mil...@linaro.org> wrote: > Bill: > S19: When you write:"These addresses are intended to be used within > the scope of the calling thread and should not be assumed to have any > validity outside of that context", do you really mean

Re: [lng-odp] thread/shmem discussion summary V4

Bill: S19: When you write:"These addresses are intended to be used within the scope of the calling thread and should not be assumed to have any validity outside of that context", do you really mean this, regardless on how ODP threads are implemented? Jerrin: S18: your answer to S18 is confusing

Re: [lng-odp] thread/shmem discussion summary V4

On Wed, Jun 8, 2016 at 10:54 AM, Yi He wrote: > Hi, Christophe and team > > For the shmem part: > > S18: yes > S19, S20: I agree with Bill's comments are very accurate and formalized. > > S21: to cover the case shm addresses(pointers) passed within data structure > > especially

Re: [lng-odp] thread/shmem discussion summary V4

Hi, Christophe and team For the shmem part: S18: yes S19, S20: I agree with Bill's comments are very accurate and formalized. S21: to cover the case shm addresses(pointers) passed within data structure especially think of cases: 3) Context pointer getters (odp_queue_context(),

Re: [lng-odp] thread/shmem discussion summary V4

Thanks Jerin, I have merged your comments into the doc: there were many points you did not comments (not sure whether the yes below a group applied to the group of statement). You can review the doc to make sure I did not corrupt your feelings :-) once again, Thanks Christophe. On 8 June 2016

Re: [lng-odp] thread/shmem discussion summary V4

On Fri, Jun 03, 2016 at 11:15:43AM +0200, Christophe Milard wrote: > since V3: Update following Bill's comments > since V2: Update following Barry and Bill's comments > since V1: Update following arch call 31 may 2016 > > This is a tentative to sum up the discussions around the thread/process >

Re: [lng-odp] thread/shmem discussion summary V4

Hi, thanks Christophe and happy to discuss with and learn from team in yesterday's ARCH call :) The question which triggers this kind of thinking is: how to use ODP as a framework to produce re-usable building blocks to compose "Network Function Instance" in runtime, since until runtime it will

Re: [lng-odp] thread/shmem discussion summary V4

On 7 June 2016 at 10:22, Yi He wrote: > Hi, team > > I send my thoughts on the ODP thread part: > > S1, S2, S3, S4 > Yi: Yes > This set of statements defines ODP thread concept as a higher > level abstraction of underlying concurrent execution context. > > S5, S6, S7, S8, S9,

Re: [lng-odp] thread/shmem discussion summary V4

Hi, team I send my thoughts on the ODP thread part: S1, S2, S3, S4 Yi: Yes This set of statements defines ODP thread concept as a higher level abstraction of underlying concurrent execution context. S5, S6, S7, S8, S9, S10: Yi: Yes This set of statements add several constraints upon ODP

[lng-odp] thread/shmem discussion summary V4

since V3: Update following Bill's comments since V2: Update following Barry and Bill's comments since V1: Update following arch call 31 may 2016 This is a tentative to sum up the discussions around the thread/process that have been happening these last weeks. Sorry for the formalism of this mail,