| Message ID | 1438135016-22225-6-git-send-email-bill.fischofer@linaro.org |
|---|---|
| State | New |
| Headers | show |
This change (having an "ordered context" per event) brings up (again) the question of how do we handle the case when a packet coming in from an ordered queue needs fragmentation before going to next processing stage. As related to this, how do we insert locally generated packets into an ordered flow, without enqueuing them first into an ordered queue so they would get an "ordered context" when dequeued. I think we would need functions to associate events with a given ordered context. Thanks, Alex On 29 July 2015 at 04:56, Bill Fischofer <bill.fischofer@linaro.org> wrote: > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> > --- > include/odp/api/schedule.h | 24 +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > > diff --git a/include/odp/api/schedule.h b/include/odp/api/schedule.h > index d679510..3f62c46 100644 > --- a/include/odp/api/schedule.h > +++ b/include/odp/api/schedule.h > @@ -147,21 +147,23 @@ void odp_schedule_resume(void); > void odp_schedule_release_atomic(void); > > /** > - * Release the current ordered context > + * Release the ordered context associated with an event > * > - * This call is valid only for source queues with ordered > synchronization. It > - * hints the scheduler that the user has done all enqueues that need to > maintain > - * event order in the current ordered context. The scheduler is allowed to > - * release the ordered context of this thread and avoid reordering any > following > - * enqueues. However, the context may be still held until the next > - * odp_schedule() or odp_schedule_multi() call - this call allows but > does not > - * force the scheduler to release the context early. > + * This call tells the scheduler that order no longer needs to be > maintained > + * for the specified event. This call is needed if, for example, the > caller > + * will free or otherwise dispose of an event that came from an ordered > queue > + * without enqueuing it to another queue. This call does not effect the > + * ordering associated with any other event held by the caller. > * > * Early ordered context release may increase parallelism and thus system > - * performance, since scheduler may start reordering events sooner than > the next > - * schedule call. > + * performance, since scheduler may start reordering events sooner than > the > + * next schedule call. > + * > + * @param ev The event to be released from order preservation. If the > + * specified event did not originate from an ordered queue > + * this call does nothing. > */ > -void odp_schedule_release_ordered(void); > +void odp_schedule_release_ordered(odp_event_t ev); > > /** > * Prefetch events for next schedule call > -- > 2.1.4 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
Yes, this is why I wanted to discuss this further since the question of how you handle fragmentation and reassembly is one of the key "grey areas" in the current spec. These are practical use cases of the more general question of how to you insert and delete events into an existing order sequence while still preserving overall ordering. I think the root issue here is that Atomic and Ordered are queue properties but these are scheduler APIs, so (implicitly) they refer to the queue that was last selected by the scheduler to provide event(s) to this thread. However, threads can do their own dequeues from atomic and ordered queues that are of type ODP_QUEUE_TYPE_POLL. Events from these queues also have Atomic and Ordered semantics and yet we don't have corresponding odp_queue_release_atomic() and odp_queue_release_ordered() calls. Perhaps we should. On Wed, Jul 29, 2015 at 3:39 AM, Alexandru Badicioiu < alexandru.badicioiu@linaro.org> wrote: > This change (having an "ordered context" per event) brings up (again) the > question of how do we handle the case when a packet coming in from an > ordered queue needs fragmentation before going to next processing stage. As > related to this, how do we insert locally generated packets into an ordered > flow, without enqueuing them first into an ordered queue so they would get > an "ordered context" when dequeued. > I think we would need functions to associate events with a given ordered > context. > > Thanks, > Alex > > > On 29 July 2015 at 04:56, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >> >> --- >> include/odp/api/schedule.h | 24 +++++++++++++----------- >> 1 file changed, 13 insertions(+), 11 deletions(-) >> >> diff --git a/include/odp/api/schedule.h b/include/odp/api/schedule.h >> index d679510..3f62c46 100644 >> --- a/include/odp/api/schedule.h >> +++ b/include/odp/api/schedule.h >> @@ -147,21 +147,23 @@ void odp_schedule_resume(void); >> void odp_schedule_release_atomic(void); >> >> /** >> - * Release the current ordered context >> + * Release the ordered context associated with an event >> * >> - * This call is valid only for source queues with ordered >> synchronization. It >> - * hints the scheduler that the user has done all enqueues that need to >> maintain >> - * event order in the current ordered context. The scheduler is allowed >> to >> - * release the ordered context of this thread and avoid reordering any >> following >> - * enqueues. However, the context may be still held until the next >> - * odp_schedule() or odp_schedule_multi() call - this call allows but >> does not >> - * force the scheduler to release the context early. >> + * This call tells the scheduler that order no longer needs to be >> maintained >> + * for the specified event. This call is needed if, for example, the >> caller >> + * will free or otherwise dispose of an event that came from an ordered >> queue >> + * without enqueuing it to another queue. This call does not effect the >> + * ordering associated with any other event held by the caller. >> * >> * Early ordered context release may increase parallelism and thus system >> - * performance, since scheduler may start reordering events sooner than >> the next >> - * schedule call. >> + * performance, since scheduler may start reordering events sooner than >> the >> + * next schedule call. >> + * >> + * @param ev The event to be released from order preservation. If >> the >> + * specified event did not originate from an ordered queue >> + * this call does nothing. >> */ >> -void odp_schedule_release_ordered(void); >> +void odp_schedule_release_ordered(odp_event_t ev); >> >> /** >> * Prefetch events for next schedule call >> -- >> 2.1.4 >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > >
My understanding is that POLL type queues don't have any scheduling attributes, since their scheduler is the application itself. Atomic context is not really an event attribute - it's a queue attribute which enforces the scheduler to return an event from the queue only when no other event from the same queue is in process (or the same atomic context is the current one). Ordered context, on the other hand, seems more like an event attribute since we can have many events from the same ordered queue in process - releasing an event ordered context simply means to tell the order restoration at next enqueue it can go without this event (wasn't there a skip_order() function?). Related to scheduling queue contexts - there was a discussion that there's a single implicit queue context after each return of odp_schedule() , so two consecutive calls of odp_schedule() : ev1 = odp_schedule(); ev2 = odp_schedule(); can return events only from the same queue. Doing an: odp_schedule_release_atomic/ordered() will allow the scheduler to return an event from another queue at next invocation: ev3 = odp_schedule(); Hope this helps, Alex On 29 July 2015 at 13:32, Bill Fischofer <bill.fischofer@linaro.org> wrote: > Yes, this is why I wanted to discuss this further since the question of > how you handle fragmentation and reassembly is one of the key "grey areas" > in the current spec. These are practical use cases of the more general > question of how to you insert and delete events into an existing order > sequence while still preserving overall ordering. > > I think the root issue here is that Atomic and Ordered are queue > properties but these are scheduler APIs, so (implicitly) they refer to the > queue that was last selected by the scheduler to provide event(s) to this > thread. However, threads can do their own dequeues from atomic and ordered > queues that are of type ODP_QUEUE_TYPE_POLL. Events from these queues also > have Atomic and Ordered semantics and yet we don't have corresponding > odp_queue_release_atomic() and odp_queue_release_ordered() calls. Perhaps > we should. > > On Wed, Jul 29, 2015 at 3:39 AM, Alexandru Badicioiu < > alexandru.badicioiu@linaro.org> wrote: > >> This change (having an "ordered context" per event) brings up (again) the >> question of how do we handle the case when a packet coming in from an >> ordered queue needs fragmentation before going to next processing stage. As >> related to this, how do we insert locally generated packets into an ordered >> flow, without enqueuing them first into an ordered queue so they would get >> an "ordered context" when dequeued. >> I think we would need functions to associate events with a given ordered >> context. >> >> Thanks, >> Alex >> >> >> On 29 July 2015 at 04:56, Bill Fischofer <bill.fischofer@linaro.org> >> wrote: >> >>> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >>> >>> --- >>> include/odp/api/schedule.h | 24 +++++++++++++----------- >>> 1 file changed, 13 insertions(+), 11 deletions(-) >>> >>> diff --git a/include/odp/api/schedule.h b/include/odp/api/schedule.h >>> index d679510..3f62c46 100644 >>> --- a/include/odp/api/schedule.h >>> +++ b/include/odp/api/schedule.h >>> @@ -147,21 +147,23 @@ void odp_schedule_resume(void); >>> void odp_schedule_release_atomic(void); >>> >>> /** >>> - * Release the current ordered context >>> + * Release the ordered context associated with an event >>> * >>> - * This call is valid only for source queues with ordered >>> synchronization. It >>> - * hints the scheduler that the user has done all enqueues that need to >>> maintain >>> - * event order in the current ordered context. The scheduler is allowed >>> to >>> - * release the ordered context of this thread and avoid reordering any >>> following >>> - * enqueues. However, the context may be still held until the next >>> - * odp_schedule() or odp_schedule_multi() call - this call allows but >>> does not >>> - * force the scheduler to release the context early. >>> + * This call tells the scheduler that order no longer needs to be >>> maintained >>> + * for the specified event. This call is needed if, for example, the >>> caller >>> + * will free or otherwise dispose of an event that came from an ordered >>> queue >>> + * without enqueuing it to another queue. This call does not effect the >>> + * ordering associated with any other event held by the caller. >>> * >>> * Early ordered context release may increase parallelism and thus >>> system >>> - * performance, since scheduler may start reordering events sooner than >>> the next >>> - * schedule call. >>> + * performance, since scheduler may start reordering events sooner than >>> the >>> + * next schedule call. >>> + * >>> + * @param ev The event to be released from order preservation. If >>> the >>> + * specified event did not originate from an ordered >>> queue >>> + * this call does nothing. >>> */ >>> -void odp_schedule_release_ordered(void); >>> +void odp_schedule_release_ordered(odp_event_t ev); >>> >>> /** >>> * Prefetch events for next schedule call >>> -- >>> 2.1.4 >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >
On 29.07.15 17:24, Alexandru Badicioiu wrote: > My understanding is that POLL type queues don't have any scheduling > attributes, since their scheduler is the application itself. Atomic > context is not really an event attribute - it's a queue attribute which > enforces the scheduler to return an event from the queue only when no > other event from the same queue is in process (or the same atomic > context is the current one). Ordered context, on the other hand, seems > more like an event attribute since we can have many events from the same > ordered queue in process - releasing an event ordered context simply > means to tell the order restoration at next enqueue it can go without > this event (wasn't there a skip_order() function?). > > Related to scheduling queue contexts - there was a discussion that > there's a single implicit queue context after each return of > odp_schedule() , so two consecutive calls of odp_schedule() : > ev1 = odp_schedule(); > ev2 = odp_schedule(); > can return events only from the same queue. > Doing an: > odp_schedule_release_atomic/ordered() > will allow the scheduler to return an event from another queue at next > invocation: > ev3 = odp_schedule(); > > Hope this helps, > Alex I supposed odp_schedule_release_ordered() controls ability of queue to return next event from given ordered queue. An event always knows the "source" queue, so instead of queue we can pass event to this function. odp_schedule_release_ordered() is used in case if thread wants to say that OK, I've finished with this ordered event, and I allow to take the next ordered event from the same queue I just received to another some thread. The thread that calls odp_schedule_release_ordered() knows when it can allow receiving of next event by some another thread from ordered group for sure. That mean that thread simply finished with the event and has some anther work to do (or sleep), and allows to receive from given ordered queue someone else. But I don't understand one thing. When it calls odp_schedule() one by one w/o "release" it doesn't mean that this thread will receive the event from the same ordered queue. It can be another ordered queue? The odp_schedule() not explicitly calls "release" for thread that called it, allowing to receive event, but it doesn't mean that it will be the same thread. Correct me if I'm wrong. > > On 29 July 2015 at 13:32, Bill Fischofer <bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>> wrote: > > Yes, this is why I wanted to discuss this further since the question > of how you handle fragmentation and reassembly is one of the key > "grey areas" in the current spec. These are practical use cases of > the more general question of how to you insert and delete events > into an existing order sequence while still preserving overall ordering. > > I think the root issue here is that Atomic and Ordered are queue > properties but these are scheduler APIs, so (implicitly) they refer > to the queue that was last selected by the scheduler to provide > event(s) to this thread. However, threads can do their own dequeues > from atomic and ordered queues that are of type > ODP_QUEUE_TYPE_POLL. Events from these queues also have Atomic and > Ordered semantics and yet we don't have corresponding > odp_queue_release_atomic() and odp_queue_release_ordered() calls. > Perhaps we should. > > On Wed, Jul 29, 2015 at 3:39 AM, Alexandru Badicioiu > <alexandru.badicioiu@linaro.org > <mailto:alexandru.badicioiu@linaro.org>> wrote: > > This change (having an "ordered context" per event) brings up > (again) the question of how do we handle the case when a packet > coming in from an ordered queue needs fragmentation before going > to next processing stage. As related to this, how do we insert > locally generated packets into an ordered flow, without > enqueuing them first into an ordered queue so they would get an > "ordered context" when dequeued. > I think we would need functions to associate events with a given > ordered context. > > Thanks, > Alex > > On 29 July 2015 at 04:56, Bill Fischofer > <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> > wrote: > > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>> > > --- > include/odp/api/schedule.h | 24 +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > > diff --git a/include/odp/api/schedule.h > b/include/odp/api/schedule.h > index d679510..3f62c46 100644 > --- a/include/odp/api/schedule.h > +++ b/include/odp/api/schedule.h > @@ -147,21 +147,23 @@ void odp_schedule_resume(void); > void odp_schedule_release_atomic(void); > > /** > - * Release the current ordered context > + * Release the ordered context associated with an event > * > - * This call is valid only for source queues with ordered > synchronization. It > - * hints the scheduler that the user has done all enqueues > that need to maintain > - * event order in the current ordered context. The > scheduler is allowed to > - * release the ordered context of this thread and avoid > reordering any following > - * enqueues. However, the context may be still held until > the next > - * odp_schedule() or odp_schedule_multi() call - this call > allows but does not > - * force the scheduler to release the context early. > + * This call tells the scheduler that order no longer needs > to be maintained > + * for the specified event. This call is needed if, for > example, the caller > + * will free or otherwise dispose of an event that came > from an ordered queue > + * without enqueuing it to another queue. This call does > not effect the > + * ordering associated with any other event held by the caller. > * > * Early ordered context release may increase parallelism > and thus system > - * performance, since scheduler may start reordering events > sooner than the next > - * schedule call. > + * performance, since scheduler may start reordering events > sooner than the > + * next schedule call. > + * > + * @param ev The event to be released from order > preservation. If the > + * specified event did not originate from an > ordered queue > + * this call does nothing. > */ > -void odp_schedule_release_ordered(void); > +void odp_schedule_release_ordered(odp_event_t ev); > > /** > * Prefetch events for next schedule call > -- > 2.1.4 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
Ordering refers to what happens on subsequent enqs of events received from an ordered queue. An ordered queue is the same as a parallel queue in that the scheduler will dispatch events form it to multiple threads in parallel. However, when those threads subsequently enq their events the order in which those downstream enqs will occur will match the order that they had on the originating queue independent of the sequence in which the threads issued the enq operations. This is because the implementation maintains an ordering of these events and implicitly holds them in a reorder queue associated within the originating queue as needed to ensure that they are not reordered downstream. A release_ordered() call would logically remove an event from this implied ordering, allowing it to be processed independently without regard to its relative order with respect to other items originating from the same ordered queue. In effect, after a release_ordered() call the event behaves as if it came from a parallel queue rather than an ordered one. On Wed, Jul 29, 2015 at 10:36 AM, Ivan Khoronzhuk < ivan.khoronzhuk@linaro.org> wrote: > > > On 29.07.15 17:24, Alexandru Badicioiu wrote: > >> My understanding is that POLL type queues don't have any scheduling >> attributes, since their scheduler is the application itself. Atomic >> context is not really an event attribute - it's a queue attribute which >> enforces the scheduler to return an event from the queue only when no >> other event from the same queue is in process (or the same atomic >> context is the current one). Ordered context, on the other hand, seems >> more like an event attribute since we can have many events from the same >> ordered queue in process - releasing an event ordered context simply >> means to tell the order restoration at next enqueue it can go without >> this event (wasn't there a skip_order() function?). >> >> Related to scheduling queue contexts - there was a discussion that >> there's a single implicit queue context after each return of >> odp_schedule() , so two consecutive calls of odp_schedule() : >> ev1 = odp_schedule(); >> ev2 = odp_schedule(); >> can return events only from the same queue. >> Doing an: >> odp_schedule_release_atomic/ordered() >> will allow the scheduler to return an event from another queue at next >> invocation: >> ev3 = odp_schedule(); >> >> Hope this helps, >> Alex >> > > I supposed odp_schedule_release_ordered() controls ability of queue to > return next event from given ordered queue. An event always knows the > "source" queue, so instead of queue we can pass event to this function. > > odp_schedule_release_ordered() is used in case if thread wants to say > that OK, I've finished with this ordered event, and I allow to take the > next ordered event from the same queue I just received to another some > thread. The thread that calls odp_schedule_release_ordered() knows when > it can allow receiving of next event by some another thread from > ordered group for sure. That mean that thread simply finished with the > event and has some anther work to do (or sleep), and allows to receive > from given ordered queue someone else. > > But I don't understand one thing. When it calls odp_schedule() one by > one w/o "release" it doesn't mean that this thread will receive the > event from the same ordered queue. It can be another ordered queue? > The odp_schedule() not explicitly calls "release" for thread > that called it, allowing to receive event, but it doesn't mean that > it will be the same thread. > > Correct me if I'm wrong. > > >> On 29 July 2015 at 13:32, Bill Fischofer <bill.fischofer@linaro.org >> <mailto:bill.fischofer@linaro.org>> wrote: >> >> Yes, this is why I wanted to discuss this further since the question >> of how you handle fragmentation and reassembly is one of the key >> "grey areas" in the current spec. These are practical use cases of >> the more general question of how to you insert and delete events >> into an existing order sequence while still preserving overall >> ordering. >> >> I think the root issue here is that Atomic and Ordered are queue >> properties but these are scheduler APIs, so (implicitly) they refer >> to the queue that was last selected by the scheduler to provide >> event(s) to this thread. However, threads can do their own dequeues >> from atomic and ordered queues that are of type >> ODP_QUEUE_TYPE_POLL. Events from these queues also have Atomic and >> Ordered semantics and yet we don't have corresponding >> odp_queue_release_atomic() and odp_queue_release_ordered() calls. >> Perhaps we should. >> >> On Wed, Jul 29, 2015 at 3:39 AM, Alexandru Badicioiu >> <alexandru.badicioiu@linaro.org >> <mailto:alexandru.badicioiu@linaro.org>> wrote: >> >> This change (having an "ordered context" per event) brings up >> (again) the question of how do we handle the case when a packet >> coming in from an ordered queue needs fragmentation before going >> to next processing stage. As related to this, how do we insert >> locally generated packets into an ordered flow, without >> enqueuing them first into an ordered queue so they would get an >> "ordered context" when dequeued. >> I think we would need functions to associate events with a given >> ordered context. >> >> Thanks, >> Alex >> >> On 29 July 2015 at 04:56, Bill Fischofer >> <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org>> >> wrote: >> >> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org >> <mailto:bill.fischofer@linaro.org>> >> >> >> --- >> include/odp/api/schedule.h | 24 +++++++++++++----------- >> 1 file changed, 13 insertions(+), 11 deletions(-) >> >> diff --git a/include/odp/api/schedule.h >> b/include/odp/api/schedule.h >> index d679510..3f62c46 100644 >> --- a/include/odp/api/schedule.h >> +++ b/include/odp/api/schedule.h >> @@ -147,21 +147,23 @@ void odp_schedule_resume(void); >> void odp_schedule_release_atomic(void); >> >> /** >> - * Release the current ordered context >> + * Release the ordered context associated with an event >> * >> - * This call is valid only for source queues with ordered >> synchronization. It >> - * hints the scheduler that the user has done all enqueues >> that need to maintain >> - * event order in the current ordered context. The >> scheduler is allowed to >> - * release the ordered context of this thread and avoid >> reordering any following >> - * enqueues. However, the context may be still held until >> the next >> - * odp_schedule() or odp_schedule_multi() call - this call >> allows but does not >> - * force the scheduler to release the context early. >> + * This call tells the scheduler that order no longer needs >> to be maintained >> + * for the specified event. This call is needed if, for >> example, the caller >> + * will free or otherwise dispose of an event that came >> from an ordered queue >> + * without enqueuing it to another queue. This call does >> not effect the >> + * ordering associated with any other event held by the >> caller. >> * >> * Early ordered context release may increase parallelism >> and thus system >> - * performance, since scheduler may start reordering events >> sooner than the next >> - * schedule call. >> + * performance, since scheduler may start reordering events >> sooner than the >> + * next schedule call. >> + * >> + * @param ev The event to be released from order >> preservation. If the >> + * specified event did not originate from an >> ordered queue >> + * this call does nothing. >> */ >> -void odp_schedule_release_ordered(void); >> +void odp_schedule_release_ordered(odp_event_t ev); >> >> /** >> * Prefetch events for next schedule call >> -- >> 2.1.4 >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> > -- > Regards, > Ivan Khoronzhuk > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
Thanks Bill. All in order now. On 29.07.15 20:58, Bill Fischofer wrote: > Ordering refers to what happens on subsequent enqs of events received > from an ordered queue. An ordered queue is the same as a parallel queue > in that the scheduler will dispatch events form it to multiple threads > in parallel. However, when those threads subsequently enq their events > the order in which those downstream enqs will occur will match the order > that they had on the originating queue independent of the sequence in > which the threads issued the enq operations. This is because the > implementation maintains an ordering of these events and implicitly > holds them in a reorder queue associated within the originating queue as > needed to ensure that they are not reordered downstream. > > A release_ordered() call would logically remove an event from this > implied ordering, allowing it to be processed independently without > regard to its relative order with respect to other items originating > from the same ordered queue. In effect, after a release_ordered() call > the event behaves as if it came from a parallel queue rather than an > ordered one. > > On Wed, Jul 29, 2015 at 10:36 AM, Ivan Khoronzhuk > <ivan.khoronzhuk@linaro.org <mailto:ivan.khoronzhuk@linaro.org>> wrote: > > > > On 29.07.15 17:24, Alexandru Badicioiu wrote: > > My understanding is that POLL type queues don't have any scheduling > attributes, since their scheduler is the application itself. Atomic > context is not really an event attribute - it's a queue > attribute which > enforces the scheduler to return an event from the queue only > when no > other event from the same queue is in process (or the same atomic > context is the current one). Ordered context, on the other hand, > seems > more like an event attribute since we can have many events from > the same > ordered queue in process - releasing an event ordered context simply > means to tell the order restoration at next enqueue it can go > without > this event (wasn't there a skip_order() function?). > > Related to scheduling queue contexts - there was a discussion that > there's a single implicit queue context after each return of > odp_schedule() , so two consecutive calls of odp_schedule() : > ev1 = odp_schedule(); > ev2 = odp_schedule(); > can return events only from the same queue. > Doing an: > odp_schedule_release_atomic/ordered() > will allow the scheduler to return an event from another queue > at next > invocation: > ev3 = odp_schedule(); > > Hope this helps, > Alex > > > I supposed odp_schedule_release_ordered() controls ability of queue to > return next event from given ordered queue. An event always knows the > "source" queue, so instead of queue we can pass event to this function. > > odp_schedule_release_ordered() is used in case if thread wants to say > that OK, I've finished with this ordered event, and I allow to take the > next ordered event from the same queue I just received to another some > thread. The thread that calls odp_schedule_release_ordered() knows when > it can allow receiving of next event by some another thread from > ordered group for sure. That mean that thread simply finished with the > event and has some anther work to do (or sleep), and allows to receive > from given ordered queue someone else. > > But I don't understand one thing. When it calls odp_schedule() one by > one w/o "release" it doesn't mean that this thread will receive the > event from the same ordered queue. It can be another ordered queue? > The odp_schedule() not explicitly calls "release" for thread > that called it, allowing to receive event, but it doesn't mean that > it will be the same thread. > > Correct me if I'm wrong. > > > On 29 July 2015 at 13:32, Bill Fischofer > <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org> > <mailto:bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>>> wrote: > > Yes, this is why I wanted to discuss this further since the > question > of how you handle fragmentation and reassembly is one of > the key > "grey areas" in the current spec. These are practical use > cases of > the more general question of how to you insert and delete > events > into an existing order sequence while still preserving > overall ordering. > > I think the root issue here is that Atomic and Ordered are > queue > properties but these are scheduler APIs, so (implicitly) > they refer > to the queue that was last selected by the scheduler to provide > event(s) to this thread. However, threads can do their own > dequeues > from atomic and ordered queues that are of type > ODP_QUEUE_TYPE_POLL. Events from these queues also have > Atomic and > Ordered semantics and yet we don't have corresponding > odp_queue_release_atomic() and odp_queue_release_ordered() > calls. > Perhaps we should. > > On Wed, Jul 29, 2015 at 3:39 AM, Alexandru Badicioiu > <alexandru.badicioiu@linaro.org > <mailto:alexandru.badicioiu@linaro.org> > <mailto:alexandru.badicioiu@linaro.org > <mailto:alexandru.badicioiu@linaro.org>>> wrote: > > This change (having an "ordered context" per event) > brings up > (again) the question of how do we handle the case when > a packet > coming in from an ordered queue needs fragmentation > before going > to next processing stage. As related to this, how do we > insert > locally generated packets into an ordered flow, without > enqueuing them first into an ordered queue so they > would get an > "ordered context" when dequeued. > I think we would need functions to associate events > with a given > ordered context. > > Thanks, > Alex > > On 29 July 2015 at 04:56, Bill Fischofer > <bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org> > <mailto:bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>>> > wrote: > > Signed-off-by: Bill Fischofer > <bill.fischofer@linaro.org <mailto:bill.fischofer@linaro.org> > <mailto:bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>>> > > > --- > include/odp/api/schedule.h | 24 > +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > > diff --git a/include/odp/api/schedule.h > b/include/odp/api/schedule.h > index d679510..3f62c46 100644 > --- a/include/odp/api/schedule.h > +++ b/include/odp/api/schedule.h > @@ -147,21 +147,23 @@ void odp_schedule_resume(void); > void odp_schedule_release_atomic(void); > > /** > - * Release the current ordered context > + * Release the ordered context associated with an > event > * > - * This call is valid only for source queues with > ordered > synchronization. It > - * hints the scheduler that the user has done all > enqueues > that need to maintain > - * event order in the current ordered context. The > scheduler is allowed to > - * release the ordered context of this thread and > avoid > reordering any following > - * enqueues. However, the context may be still > held until > the next > - * odp_schedule() or odp_schedule_multi() call - > this call > allows but does not > - * force the scheduler to release the context early. > + * This call tells the scheduler that order no > longer needs > to be maintained > + * for the specified event. This call is needed > if, for > example, the caller > + * will free or otherwise dispose of an event that > came > from an ordered queue > + * without enqueuing it to another queue. This > call does > not effect the > + * ordering associated with any other event held > by the caller. > * > * Early ordered context release may increase > parallelism > and thus system > - * performance, since scheduler may start > reordering events > sooner than the next > - * schedule call. > + * performance, since scheduler may start > reordering events > sooner than the > + * next schedule call. > + * > + * @param ev The event to be released from order > preservation. If the > + * specified event did not > originate from an > ordered queue > + * this call does nothing. > */ > -void odp_schedule_release_ordered(void); > +void odp_schedule_release_ordered(odp_event_t ev); > > /** > * Prefetch events for next schedule call > -- > 2.1.4 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > <mailto:lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org>> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp > > > -- > Regards, > Ivan Khoronzhuk > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/lng-odp > >
diff --git a/include/odp/api/schedule.h b/include/odp/api/schedule.h index d679510..3f62c46 100644 --- a/include/odp/api/schedule.h +++ b/include/odp/api/schedule.h @@ -147,21 +147,23 @@ void odp_schedule_resume(void); void odp_schedule_release_atomic(void); /** - * Release the current ordered context + * Release the ordered context associated with an event * - * This call is valid only for source queues with ordered synchronization. It - * hints the scheduler that the user has done all enqueues that need to maintain - * event order in the current ordered context. The scheduler is allowed to - * release the ordered context of this thread and avoid reordering any following - * enqueues. However, the context may be still held until the next - * odp_schedule() or odp_schedule_multi() call - this call allows but does not - * force the scheduler to release the context early. + * This call tells the scheduler that order no longer needs to be maintained + * for the specified event. This call is needed if, for example, the caller + * will free or otherwise dispose of an event that came from an ordered queue + * without enqueuing it to another queue. This call does not effect the + * ordering associated with any other event held by the caller. * * Early ordered context release may increase parallelism and thus system - * performance, since scheduler may start reordering events sooner than the next - * schedule call. + * performance, since scheduler may start reordering events sooner than the + * next schedule call. + * + * @param ev The event to be released from order preservation. If the + * specified event did not originate from an ordered queue + * this call does nothing. */ -void odp_schedule_release_ordered(void); +void odp_schedule_release_ordered(odp_event_t ev); /** * Prefetch events for next schedule call
Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> --- include/odp/api/schedule.h | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-)