| Message ID | 1450799798-26458-2-git-send-email-bill.fischofer@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On 22 December 2015 at 10:56, Bill Fischofer <bill.fischofer@linaro.org> wrote: > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> > --- > doc/users-guide/users-guide.adoc | 27 ++++++++++++++++----------- > 1 file changed, 16 insertions(+), 11 deletions(-) > > diff --git a/doc/users-guide/users-guide.adoc > b/doc/users-guide/users-guide.adoc > index 7ec7957..fa8990a 100644 > --- a/doc/users-guide/users-guide.adoc > +++ b/doc/users-guide/users-guide.adoc > @@ -623,24 +623,29 @@ might either be empty, of lower priority, or not in > a scheduler group matching > any of the threads being serviced by the scheduler. > > === Atomic Queues > -Atomic queues simplify event synchronization because only a single event > -from a given atomic queue may be processed at a time. Events scheduled > from > +Atomic queues simplify event synchronization because only a single thread > may > +process event(s) from a given atomic queue at a time. Events scheduled > from > atomic queues thus can be processed lock free because the locking is being > -done implicitly by the scheduler. > +done implicitly by the scheduler. Note that the caller may receive one or > Do we want to highlight this note with [NOTE] Note that the caller may receive one or > +more events from the same atomic queue if *odp_schedule_multi()* is used. > In > +this case any required synchronization between these events is the > +responsibility of the caller as the scheduler's context synchronization > support > +for atomic queues extends only to calls from different threads. > > .Atomic Queue Scheduling > image::../images/atomic_queue.png[align="center"] > > -In this example, no matter how many events may be held in an atomic > queue, only > -one of them can be scheduled at a time. Here two threads process events > from > -two different atomic queues. Note that there is no synchronization between > -different atomic queues, only between events originating from the same > atomic > -queue. The queue context associated with the atomic queue is held until > the > -next call to the scheduler or until the application explicitly releases it > -via a call to *odp_schedule_release_atomic()*. > +In this example, no matter how many events may be held in an atomic queue, > +only one calling thread can receive scheduled events from it at a time. > Here > +two threads process events from two different atomic queues. Note that > there > +is no synchronization between different atomic queues, only between events > +originating from the same atomic queue. The queue context associated with > the > +atomic queue is held until the next call to the scheduler or until the > +application explicitly releases it via a call to > +*odp_schedule_release_atomic()*. > > Note that while atomic queues simplify programming, the serial nature of > Do we want to highlight this note with [NOTE] Note that while atomic queues simplify programming, the serial nature of > -atomic queues will impair scaling. > +atomic queues may impair scaling. > > === Ordered Queues > Ordered queues provide the best of both worlds by providing the inherent > -- > 2.5.0 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
I'm not sure if those parenthetical remarks need a huge callout, but I have no objection to making that change if you feel strongly about it. On Tue, Jan 5, 2016 at 3:25 PM, Mike Holmes <mike.holmes@linaro.org> wrote: > > > On 22 December 2015 at 10:56, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >> --- >> doc/users-guide/users-guide.adoc | 27 ++++++++++++++++----------- >> 1 file changed, 16 insertions(+), 11 deletions(-) >> >> diff --git a/doc/users-guide/users-guide.adoc >> b/doc/users-guide/users-guide.adoc >> index 7ec7957..fa8990a 100644 >> --- a/doc/users-guide/users-guide.adoc >> +++ b/doc/users-guide/users-guide.adoc >> @@ -623,24 +623,29 @@ might either be empty, of lower priority, or not in >> a scheduler group matching >> any of the threads being serviced by the scheduler. >> >> === Atomic Queues >> -Atomic queues simplify event synchronization because only a single event >> -from a given atomic queue may be processed at a time. Events scheduled >> from >> +Atomic queues simplify event synchronization because only a single >> thread may >> +process event(s) from a given atomic queue at a time. Events scheduled >> from >> atomic queues thus can be processed lock free because the locking is >> being >> -done implicitly by the scheduler. >> +done implicitly by the scheduler. Note that the caller may receive one or >> > > Do we want to highlight this note with [NOTE] Note that the caller may > receive one or > > >> +more events from the same atomic queue if *odp_schedule_multi()* is >> used. In >> +this case any required synchronization between these events is the >> +responsibility of the caller as the scheduler's context synchronization >> support >> +for atomic queues extends only to calls from different threads. >> >> .Atomic Queue Scheduling >> image::../images/atomic_queue.png[align="center"] >> >> -In this example, no matter how many events may be held in an atomic >> queue, only >> -one of them can be scheduled at a time. Here two threads process events >> from >> -two different atomic queues. Note that there is no synchronization >> between >> -different atomic queues, only between events originating from the same >> atomic >> -queue. The queue context associated with the atomic queue is held until >> the >> -next call to the scheduler or until the application explicitly releases >> it >> -via a call to *odp_schedule_release_atomic()*. >> +In this example, no matter how many events may be held in an atomic >> queue, >> +only one calling thread can receive scheduled events from it at a time. >> Here >> +two threads process events from two different atomic queues. Note that >> there >> +is no synchronization between different atomic queues, only between >> events >> +originating from the same atomic queue. The queue context associated >> with the >> +atomic queue is held until the next call to the scheduler or until the >> +application explicitly releases it via a call to >> +*odp_schedule_release_atomic()*. >> >> Note that while atomic queues simplify programming, the serial nature of >> > > Do we want to highlight this note with [NOTE] Note that while atomic > queues simplify programming, the serial nature of > > >> -atomic queues will impair scaling. >> +atomic queues may impair scaling. >> >> === Ordered Queues >> Ordered queues provide the best of both worlds by providing the inherent >> -- >> 2.5.0 >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > >
On 5 January 2016 at 17:11, Bill Fischofer <bill.fischofer@linaro.org> wrote: > I'm not sure if those parenthetical remarks need a huge callout, but I > have no objection to making that change if you feel strongly about it. > I don't, it was just a question as much to highlight that we can "highlight" important notes, so I am happy. Reviewed-by: Mike Holmes <mike.holmes@linaro.org> > > On Tue, Jan 5, 2016 at 3:25 PM, Mike Holmes <mike.holmes@linaro.org> > wrote: > >> >> >> On 22 December 2015 at 10:56, Bill Fischofer <bill.fischofer@linaro.org> >> wrote: >> >>> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >>> --- >>> doc/users-guide/users-guide.adoc | 27 ++++++++++++++++----------- >>> 1 file changed, 16 insertions(+), 11 deletions(-) >>> >>> diff --git a/doc/users-guide/users-guide.adoc >>> b/doc/users-guide/users-guide.adoc >>> index 7ec7957..fa8990a 100644 >>> --- a/doc/users-guide/users-guide.adoc >>> +++ b/doc/users-guide/users-guide.adoc >>> @@ -623,24 +623,29 @@ might either be empty, of lower priority, or not >>> in a scheduler group matching >>> any of the threads being serviced by the scheduler. >>> >>> === Atomic Queues >>> -Atomic queues simplify event synchronization because only a single event >>> -from a given atomic queue may be processed at a time. Events scheduled >>> from >>> +Atomic queues simplify event synchronization because only a single >>> thread may >>> +process event(s) from a given atomic queue at a time. Events scheduled >>> from >>> atomic queues thus can be processed lock free because the locking is >>> being >>> -done implicitly by the scheduler. >>> +done implicitly by the scheduler. Note that the caller may receive one >>> or >>> >> >> Do we want to highlight this note with [NOTE] Note that the caller may >> receive one or >> >> >>> +more events from the same atomic queue if *odp_schedule_multi()* is >>> used. In >>> +this case any required synchronization between these events is the >>> +responsibility of the caller as the scheduler's context synchronization >>> support >>> +for atomic queues extends only to calls from different threads. >>> >>> .Atomic Queue Scheduling >>> image::../images/atomic_queue.png[align="center"] >>> >>> -In this example, no matter how many events may be held in an atomic >>> queue, only >>> -one of them can be scheduled at a time. Here two threads process events >>> from >>> -two different atomic queues. Note that there is no synchronization >>> between >>> -different atomic queues, only between events originating from the same >>> atomic >>> -queue. The queue context associated with the atomic queue is held until >>> the >>> -next call to the scheduler or until the application explicitly releases >>> it >>> -via a call to *odp_schedule_release_atomic()*. >>> +In this example, no matter how many events may be held in an atomic >>> queue, >>> +only one calling thread can receive scheduled events from it at a time. >>> Here >>> +two threads process events from two different atomic queues. Note that >>> there >>> +is no synchronization between different atomic queues, only between >>> events >>> +originating from the same atomic queue. The queue context associated >>> with the >>> +atomic queue is held until the next call to the scheduler or until the >>> +application explicitly releases it via a call to >>> +*odp_schedule_release_atomic()*. >>> >>> Note that while atomic queues simplify programming, the serial nature of >>> >> >> Do we want to highlight this note with [NOTE] Note that while atomic >> queues simplify programming, the serial nature of >> >> >>> -atomic queues will impair scaling. >>> +atomic queues may impair scaling. >>> >>> === Ordered Queues >>> Ordered queues provide the best of both worlds by providing the inherent >>> -- >>> 2.5.0 >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >> >> -- >> Mike Holmes >> Technical Manager - Linaro Networking Group >> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs >> >> >> > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
Merged. On 5 January 2016 at 17:29, Mike Holmes <mike.holmes@linaro.org> wrote: > > > On 5 January 2016 at 17:11, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> I'm not sure if those parenthetical remarks need a huge callout, but I >> have no objection to making that change if you feel strongly about it. >> > > I don't, it was just a question as much to highlight that we can > "highlight" important notes, so I am happy. > > Reviewed-by: Mike Holmes <mike.holmes@linaro.org> > > >> >> On Tue, Jan 5, 2016 at 3:25 PM, Mike Holmes <mike.holmes@linaro.org> >> wrote: >> >>> >>> >>> On 22 December 2015 at 10:56, Bill Fischofer <bill.fischofer@linaro.org> >>> wrote: >>> >>>> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >>>> --- >>>> doc/users-guide/users-guide.adoc | 27 ++++++++++++++++----------- >>>> 1 file changed, 16 insertions(+), 11 deletions(-) >>>> >>>> diff --git a/doc/users-guide/users-guide.adoc >>>> b/doc/users-guide/users-guide.adoc >>>> index 7ec7957..fa8990a 100644 >>>> --- a/doc/users-guide/users-guide.adoc >>>> +++ b/doc/users-guide/users-guide.adoc >>>> @@ -623,24 +623,29 @@ might either be empty, of lower priority, or not >>>> in a scheduler group matching >>>> any of the threads being serviced by the scheduler. >>>> >>>> === Atomic Queues >>>> -Atomic queues simplify event synchronization because only a single >>>> event >>>> -from a given atomic queue may be processed at a time. Events scheduled >>>> from >>>> +Atomic queues simplify event synchronization because only a single >>>> thread may >>>> +process event(s) from a given atomic queue at a time. Events >>>> scheduled from >>>> atomic queues thus can be processed lock free because the locking is >>>> being >>>> -done implicitly by the scheduler. >>>> +done implicitly by the scheduler. Note that the caller may receive one >>>> or >>>> >>> >>> Do we want to highlight this note with [NOTE] Note that the caller may >>> receive one or >>> >>> >>>> +more events from the same atomic queue if *odp_schedule_multi()* is >>>> used. In >>>> +this case any required synchronization between these events is the >>>> +responsibility of the caller as the scheduler's context >>>> synchronization support >>>> +for atomic queues extends only to calls from different threads. >>>> >>>> .Atomic Queue Scheduling >>>> image::../images/atomic_queue.png[align="center"] >>>> >>>> -In this example, no matter how many events may be held in an atomic >>>> queue, only >>>> -one of them can be scheduled at a time. Here two threads process >>>> events from >>>> -two different atomic queues. Note that there is no synchronization >>>> between >>>> -different atomic queues, only between events originating from the same >>>> atomic >>>> -queue. The queue context associated with the atomic queue is held >>>> until the >>>> -next call to the scheduler or until the application explicitly >>>> releases it >>>> -via a call to *odp_schedule_release_atomic()*. >>>> +In this example, no matter how many events may be held in an atomic >>>> queue, >>>> +only one calling thread can receive scheduled events from it at a >>>> time. Here >>>> +two threads process events from two different atomic queues. Note that >>>> there >>>> +is no synchronization between different atomic queues, only between >>>> events >>>> +originating from the same atomic queue. The queue context associated >>>> with the >>>> +atomic queue is held until the next call to the scheduler or until the >>>> +application explicitly releases it via a call to >>>> +*odp_schedule_release_atomic()*. >>>> >>>> Note that while atomic queues simplify programming, the serial nature >>>> of >>>> >>> >>> Do we want to highlight this note with [NOTE] Note that while atomic >>> queues simplify programming, the serial nature of >>> >>> >>>> -atomic queues will impair scaling. >>>> +atomic queues may impair scaling. >>>> >>>> === Ordered Queues >>>> Ordered queues provide the best of both worlds by providing the >>>> inherent >>>> -- >>>> 2.5.0 >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >>> >>> -- >>> Mike Holmes >>> Technical Manager - Linaro Networking Group >>> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM >>> SoCs >>> >>> >>> >> > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
diff --git a/doc/users-guide/users-guide.adoc b/doc/users-guide/users-guide.adoc index 7ec7957..fa8990a 100644 --- a/doc/users-guide/users-guide.adoc +++ b/doc/users-guide/users-guide.adoc @@ -623,24 +623,29 @@ might either be empty, of lower priority, or not in a scheduler group matching any of the threads being serviced by the scheduler. === Atomic Queues -Atomic queues simplify event synchronization because only a single event -from a given atomic queue may be processed at a time. Events scheduled from +Atomic queues simplify event synchronization because only a single thread may +process event(s) from a given atomic queue at a time. Events scheduled from atomic queues thus can be processed lock free because the locking is being -done implicitly by the scheduler. +done implicitly by the scheduler. Note that the caller may receive one or +more events from the same atomic queue if *odp_schedule_multi()* is used. In +this case any required synchronization between these events is the +responsibility of the caller as the scheduler's context synchronization support +for atomic queues extends only to calls from different threads. .Atomic Queue Scheduling image::../images/atomic_queue.png[align="center"] -In this example, no matter how many events may be held in an atomic queue, only -one of them can be scheduled at a time. Here two threads process events from -two different atomic queues. Note that there is no synchronization between -different atomic queues, only between events originating from the same atomic -queue. The queue context associated with the atomic queue is held until the -next call to the scheduler or until the application explicitly releases it -via a call to *odp_schedule_release_atomic()*. +In this example, no matter how many events may be held in an atomic queue, +only one calling thread can receive scheduled events from it at a time. Here +two threads process events from two different atomic queues. Note that there +is no synchronization between different atomic queues, only between events +originating from the same atomic queue. The queue context associated with the +atomic queue is held until the next call to the scheduler or until the +application explicitly releases it via a call to +*odp_schedule_release_atomic()*. Note that while atomic queues simplify programming, the serial nature of -atomic queues will impair scaling. +atomic queues may impair scaling. === Ordered Queues Ordered queues provide the best of both worlds by providing the inherent
Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> --- doc/users-guide/users-guide.adoc | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-)