| Message ID | 1438564655-12686-9-git-send-email-bill.fischofer@linaro.org |
|---|---|
| State | New |
| Headers | show |
Hi, I think extending the meaning of this function alone is not enough for the purpose of splitting a packet/event in an ordered flow context. There's has to be a way to tell the queuing engine/scheduler which one is the last fragment in a series , otherwise how the queuing engine/scheduler is supposed to know where to re-insert the event which was the "next" one prior splitting? Is the implicit convention that all fragments chains are sent with this call? I don't think the relation between ordered events should be determined by their relative position in the events[] array, rather we need additional API calls at the event layer to explicitly associate new packets with an ordered event context. Thanks, Alex On 3 August 2015 at 04:17, Bill Fischofer <bill.fischofer@linaro.org> wrote: > Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> > --- > include/odp/api/queue.h | 23 +++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/include/odp/api/queue.h b/include/odp/api/queue.h > index ce04eb4..5a6dbc0 100644 > --- a/include/odp/api/queue.h > +++ b/include/odp/api/queue.h > @@ -173,6 +173,29 @@ int odp_queue_enq(odp_queue_t queue, odp_event_t ev); > * > * @return Number of events actually enqueued (0 ... num) > * @retval <0 on failure > + * > + * @note odp_queue_enq_multi() serves two purposes. First, it allows > + * multiple events to be enqueued via a single call. In addition, it > + * permits multiple events to partitipate in ordering. When an event > + * originating from an ordered queue is followed by one or more events > + * that did not originate from an ordered queue, then these subsequent > + * events are "chained" to the ordered event such that they participate > + * in its ordering. This provides a convenient means for an application > + * to split a packet into multiple packets and have them retain the > + * relative order of the original packet. > + * > + * @note If multiple events originating from ordered queues are passed > + * to odp_queue_enq_multi() then they (and their associated chains, if > + * any) are handled independently. To see this, consider the following > + * array of events: uo1, uo2, o1, uo3, uo4, o2, o3, uo5. When this > + * array is passed to odp_queue_enq_multi() then unordered events uo1 and > + * uo2 will be added to queue, then ordered event o1 and the chained > + * events uo3, and uo4, will be added, then ordered event o2, then ordered > + * event o3 and the chained event uo5 will be added. In all cases, > + * unordered events that are chained to ordered events inherit the > relative > + * order of their ordered lead event. Note also that there is no > + * requirement that the ordered events passed to this routine all > originate > + * from the same ordered queue sine each is treated independently. > */ > int odp_queue_enq_multi(odp_queue_t queue, const odp_event_t events[], > int num); > > -- > 2.1.4 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
As defined here, the odp_queue_enq_multi() is the complete split, and the sequence is as specified in the list. Let's discuss this during today's Arch call. Do you have a proposed API for doing what you'd like? On Mon, Aug 3, 2015 at 1:46 AM, Alexandru Badicioiu < alexandru.badicioiu@linaro.org> wrote: > Hi, > I think extending the meaning of this function alone is not enough for the > purpose of splitting a packet/event in an ordered flow context. > There's has to be a way to tell the queuing engine/scheduler which one is > the last fragment in a series , otherwise how the queuing engine/scheduler > is supposed to know where to re-insert the event which was the "next" one > prior splitting? Is the implicit convention that all fragments chains are > sent with this call? > I don't think the relation between ordered events should be determined by > their relative position in the events[] array, rather we need additional > API calls at the event layer to explicitly associate new packets with an > ordered event context. > > Thanks, > Alex > > > > > > On 3 August 2015 at 04:17, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >> --- >> include/odp/api/queue.h | 23 +++++++++++++++++++++++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/include/odp/api/queue.h b/include/odp/api/queue.h >> index ce04eb4..5a6dbc0 100644 >> --- a/include/odp/api/queue.h >> +++ b/include/odp/api/queue.h >> @@ -173,6 +173,29 @@ int odp_queue_enq(odp_queue_t queue, odp_event_t ev); >> * >> * @return Number of events actually enqueued (0 ... num) >> * @retval <0 on failure >> + * >> + * @note odp_queue_enq_multi() serves two purposes. First, it allows >> + * multiple events to be enqueued via a single call. In addition, it >> + * permits multiple events to partitipate in ordering. When an event >> + * originating from an ordered queue is followed by one or more events >> + * that did not originate from an ordered queue, then these subsequent >> + * events are "chained" to the ordered event such that they participate >> + * in its ordering. This provides a convenient means for an application >> + * to split a packet into multiple packets and have them retain the >> + * relative order of the original packet. >> + * >> + * @note If multiple events originating from ordered queues are passed >> + * to odp_queue_enq_multi() then they (and their associated chains, if >> + * any) are handled independently. To see this, consider the following >> + * array of events: uo1, uo2, o1, uo3, uo4, o2, o3, uo5. When this >> + * array is passed to odp_queue_enq_multi() then unordered events uo1 and >> + * uo2 will be added to queue, then ordered event o1 and the chained >> + * events uo3, and uo4, will be added, then ordered event o2, then >> ordered >> + * event o3 and the chained event uo5 will be added. In all cases, >> + * unordered events that are chained to ordered events inherit the >> relative >> + * order of their ordered lead event. Note also that there is no >> + * requirement that the ordered events passed to this routine all >> originate >> + * from the same ordered queue sine each is treated independently. >> */ >> int odp_queue_enq_multi(odp_queue_t queue, const odp_event_t events[], >> int num); >> >> -- >> 2.1.4 >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > >
Shouldn't be possible to insert in an ordered flow just with odp_queue_enq()? Using odp_queue_enq_multi() only is somehow restrictive. I think ordering information should be contained in the event itself rather than which index in events[] array occupies. Alex On 3 August 2015 at 14:21, Bill Fischofer <bill.fischofer@linaro.org> wrote: > As defined here, the odp_queue_enq_multi() is the complete split, and the > sequence is as specified in the list. Let's discuss this during today's > Arch call. Do you have a proposed API for doing what you'd like? > > > > On Mon, Aug 3, 2015 at 1:46 AM, Alexandru Badicioiu < > alexandru.badicioiu@linaro.org> wrote: > >> Hi, >> I think extending the meaning of this function alone is not enough for >> the purpose of splitting a packet/event in an ordered flow context. >> There's has to be a way to tell the queuing engine/scheduler which one is >> the last fragment in a series , otherwise how the queuing engine/scheduler >> is supposed to know where to re-insert the event which was the "next" one >> prior splitting? Is the implicit convention that all fragments chains are >> sent with this call? >> I don't think the relation between ordered events should be determined by >> their relative position in the events[] array, rather we need additional >> API calls at the event layer to explicitly associate new packets with an >> ordered event context. >> >> Thanks, >> Alex >> >> >> >> >> >> On 3 August 2015 at 04:17, Bill Fischofer <bill.fischofer@linaro.org> >> wrote: >> >>> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >>> --- >>> include/odp/api/queue.h | 23 +++++++++++++++++++++++ >>> 1 file changed, 23 insertions(+) >>> >>> diff --git a/include/odp/api/queue.h b/include/odp/api/queue.h >>> index ce04eb4..5a6dbc0 100644 >>> --- a/include/odp/api/queue.h >>> +++ b/include/odp/api/queue.h >>> @@ -173,6 +173,29 @@ int odp_queue_enq(odp_queue_t queue, odp_event_t >>> ev); >>> * >>> * @return Number of events actually enqueued (0 ... num) >>> * @retval <0 on failure >>> + * >>> + * @note odp_queue_enq_multi() serves two purposes. First, it allows >>> + * multiple events to be enqueued via a single call. In addition, it >>> + * permits multiple events to partitipate in ordering. When an event >>> + * originating from an ordered queue is followed by one or more events >>> + * that did not originate from an ordered queue, then these subsequent >>> + * events are "chained" to the ordered event such that they participate >>> + * in its ordering. This provides a convenient means for an application >>> + * to split a packet into multiple packets and have them retain the >>> + * relative order of the original packet. >>> + * >>> + * @note If multiple events originating from ordered queues are passed >>> + * to odp_queue_enq_multi() then they (and their associated chains, if >>> + * any) are handled independently. To see this, consider the following >>> + * array of events: uo1, uo2, o1, uo3, uo4, o2, o3, uo5. When this >>> + * array is passed to odp_queue_enq_multi() then unordered events uo1 >>> and >>> + * uo2 will be added to queue, then ordered event o1 and the chained >>> + * events uo3, and uo4, will be added, then ordered event o2, then >>> ordered >>> + * event o3 and the chained event uo5 will be added. In all cases, >>> + * unordered events that are chained to ordered events inherit the >>> relative >>> + * order of their ordered lead event. Note also that there is no >>> + * requirement that the ordered events passed to this routine all >>> originate >>> + * from the same ordered queue sine each is treated independently. >>> */ >>> int odp_queue_enq_multi(odp_queue_t queue, const odp_event_t events[], >>> int num); >>> >>> -- >>> 2.1.4 >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >
I tried coming up with some syntax that would describe this, but was unsuccessful. The issue is that order is a property of the source queue and these split elements have no originating queue since the application is creating them. If your HW supports this feature it might be easier to model it after what you do and then see if that works for other implementations. On Mon, Aug 3, 2015 at 6:43 AM, Alexandru Badicioiu < alexandru.badicioiu@linaro.org> wrote: > Shouldn't be possible to insert in an ordered flow just with > odp_queue_enq()? Using odp_queue_enq_multi() only is somehow restrictive. I > think ordering information should be contained in the event itself rather > than which index in events[] array occupies. > > Alex > > On 3 August 2015 at 14:21, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > >> As defined here, the odp_queue_enq_multi() is the complete split, and the >> sequence is as specified in the list. Let's discuss this during today's >> Arch call. Do you have a proposed API for doing what you'd like? >> >> >> >> On Mon, Aug 3, 2015 at 1:46 AM, Alexandru Badicioiu < >> alexandru.badicioiu@linaro.org> wrote: >> >>> Hi, >>> I think extending the meaning of this function alone is not enough for >>> the purpose of splitting a packet/event in an ordered flow context. >>> There's has to be a way to tell the queuing engine/scheduler which one >>> is the last fragment in a series , otherwise how the queuing >>> engine/scheduler is supposed to know where to re-insert the event which was >>> the "next" one prior splitting? Is the implicit convention that all >>> fragments chains are sent with this call? >>> I don't think the relation between ordered events should be determined >>> by their relative position in the events[] array, rather we need additional >>> API calls at the event layer to explicitly associate new packets with an >>> ordered event context. >>> >>> Thanks, >>> Alex >>> >>> >>> >>> >>> >>> On 3 August 2015 at 04:17, Bill Fischofer <bill.fischofer@linaro.org> >>> wrote: >>> >>>> Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> >>>> --- >>>> include/odp/api/queue.h | 23 +++++++++++++++++++++++ >>>> 1 file changed, 23 insertions(+) >>>> >>>> diff --git a/include/odp/api/queue.h b/include/odp/api/queue.h >>>> index ce04eb4..5a6dbc0 100644 >>>> --- a/include/odp/api/queue.h >>>> +++ b/include/odp/api/queue.h >>>> @@ -173,6 +173,29 @@ int odp_queue_enq(odp_queue_t queue, odp_event_t >>>> ev); >>>> * >>>> * @return Number of events actually enqueued (0 ... num) >>>> * @retval <0 on failure >>>> + * >>>> + * @note odp_queue_enq_multi() serves two purposes. First, it allows >>>> + * multiple events to be enqueued via a single call. In addition, it >>>> + * permits multiple events to partitipate in ordering. When an event >>>> + * originating from an ordered queue is followed by one or more events >>>> + * that did not originate from an ordered queue, then these subsequent >>>> + * events are "chained" to the ordered event such that they participate >>>> + * in its ordering. This provides a convenient means for an application >>>> + * to split a packet into multiple packets and have them retain the >>>> + * relative order of the original packet. >>>> + * >>>> + * @note If multiple events originating from ordered queues are passed >>>> + * to odp_queue_enq_multi() then they (and their associated chains, if >>>> + * any) are handled independently. To see this, consider the following >>>> + * array of events: uo1, uo2, o1, uo3, uo4, o2, o3, uo5. When this >>>> + * array is passed to odp_queue_enq_multi() then unordered events uo1 >>>> and >>>> + * uo2 will be added to queue, then ordered event o1 and the chained >>>> + * events uo3, and uo4, will be added, then ordered event o2, then >>>> ordered >>>> + * event o3 and the chained event uo5 will be added. In all cases, >>>> + * unordered events that are chained to ordered events inherit the >>>> relative >>>> + * order of their ordered lead event. Note also that there is no >>>> + * requirement that the ordered events passed to this routine all >>>> originate >>>> + * from the same ordered queue sine each is treated independently. >>>> */ >>>> int odp_queue_enq_multi(odp_queue_t queue, const odp_event_t events[], >>>> int num); >>>> >>>> -- >>>> 2.1.4 >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> https://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >> >
diff --git a/include/odp/api/queue.h b/include/odp/api/queue.h index ce04eb4..5a6dbc0 100644 --- a/include/odp/api/queue.h +++ b/include/odp/api/queue.h @@ -173,6 +173,29 @@ int odp_queue_enq(odp_queue_t queue, odp_event_t ev); * * @return Number of events actually enqueued (0 ... num) * @retval <0 on failure + * + * @note odp_queue_enq_multi() serves two purposes. First, it allows + * multiple events to be enqueued via a single call. In addition, it + * permits multiple events to partitipate in ordering. When an event + * originating from an ordered queue is followed by one or more events + * that did not originate from an ordered queue, then these subsequent + * events are "chained" to the ordered event such that they participate + * in its ordering. This provides a convenient means for an application + * to split a packet into multiple packets and have them retain the + * relative order of the original packet. + * + * @note If multiple events originating from ordered queues are passed + * to odp_queue_enq_multi() then they (and their associated chains, if + * any) are handled independently. To see this, consider the following + * array of events: uo1, uo2, o1, uo3, uo4, o2, o3, uo5. When this + * array is passed to odp_queue_enq_multi() then unordered events uo1 and + * uo2 will be added to queue, then ordered event o1 and the chained + * events uo3, and uo4, will be added, then ordered event o2, then ordered + * event o3 and the chained event uo5 will be added. In all cases, + * unordered events that are chained to ordered events inherit the relative + * order of their ordered lead event. Note also that there is no + * requirement that the ordered events passed to this routine all originate + * from the same ordered queue sine each is treated independently. */ int odp_queue_enq_multi(odp_queue_t queue, const odp_event_t events[], int num);
Signed-off-by: Bill Fischofer <bill.fischofer@linaro.org> --- include/odp/api/queue.h | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+)