Petri Savolainen(psavol) replied on github web page:
include/odp/api/spec/event.h
line 54
@@ -141,6 +142,27 @@ odp_event_type_t odp_event_types(odp_event_t event,
int odp_event_type_multi(const odp_event_t event[], int num,
odp_event_type_t *type);
+/**
+ * Filter and convert packet events
+ *
+ * Checks event type of all input events, converts all packet events and
outputs
+ * packet handles. Returns the number packet handles outputted. Outputs the
+ * remaining, non-packet event handles to 'remain' array. Handles are outputted
+ * to both arrays in the same order those are stored in 'event' array. Both
+ * output arrays must fit 'num' elements.
+ *
+ * @param event Array of event handles
+ * @param[out] packet Packet handle array for output
+ * @param[out] remain Event handle array for output of remaining, non-packet
+ * events
+ * @param num Number of events (> 0)
+ *
+ * @return Number of packets outputted (0 ... num)
+ */
+int odp_event_filter_packet(const odp_event_t event[],
+ odp_packet_t packet[],
+ odp_event_t remain[], int num);
Comment:
Schedulers do not work that way. You cannot peak into head of schedule queue
and ignore non-packets and just select packets. Scheduler returns N events.
Also storing non-packets locally (inside scheduler SW) would not help, since
application could easily starve non-packets by polling those too seldom.
> Petri Savolainen(psavol) wrote:
> The same answer. Improved implementation efficiency and cleaner application
> code.
>> Petri Savolainen(psavol) wrote:
>> pkts = odp_schedule_multi(NULL, ODP_SCHED_NO_WAIT, ev_tbl, MAX_PKT_BURST);
>>
>> if (pkts <= 0)
>> continue;
>>
>> for (i = 0; i < pkts; i++)
>> pkt_tbl[i] = odp_packet_from_event(ev_tbl[i]);
>>
>> VS.
>>
>> odp_packet_from_event_multi(pkt_tlb, ev_tbl, num_pkts);
>>
>> 1) Single call vs. many calls makes difference when not inlined (ABI compat).
>> 2) This is not only cast, it's also a copy of the handle. Implementation may
>> be vectorized, for loop unrolled, etc.
>> 3) Depending on implementation the conversion may include additional things
>> to the handle copy: extra checks, post processing of the event, etc
>> HW/implementation specific tricks. Which would open more optimization
>> opportunity in addition to load+store.
>> 4) Application code is cleaner
>>> Petri Savolainen(psavol) wrote:
>>> The same answer. Improved implementation efficiency.
>>>> Petri Savolainen(psavol) wrote:
>>>> " Handles are outputted to both arrays in the same order those are stored
>>>> in 'event' array. "
>>>>
>>>> Events are not reordered. Packets are copied into packet[] and non-packets
>>>> into remain[]. Both arrays maintain p and np order of the original array.
>>>> Also original array is not modified.
>>>>
>>>> packet[] = p1, p2, p3
>>>> remain[] = np1, np2
>>>>> muvarov wrote
>>>>> why not odp_schedule_type(ODP_PACKET, void *array) ? I.e. if you need
>>>>> only packets then do scheduling only for packets. That has to be more
>>>>> fast than get all and then filer them.
>>>>>> muvarov wrote
>>>>>> is it valid case when odp_schedule() returns mixed events types? I.e.
>>>>>> some packets, some timeouts, some packets from one pool and packets from
>>>>>> other pool.
>>>>>>> Petri Savolainen(psavol) wrote:
>>>>>>> Application knows the configuration, so it knows when all packets (e.g.
>>>>>>> from certain queue/pkt input/etc) are allocated from the same pool.
>>>>>>> When that's the case, free implementation can be more efficient (than
>>>>>>> today) as it does not have to access/check/sort all packets of the
>>>>>>> burst. It can just free all into the pool of the first packet.
>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>> Doesn't this reorder events? As described consider an array of events
>>>>>>>> that consist of packets (p) and non-packets (np).
>>>>>>>>
>>>>>>>> With an input array of events: np1, p1, np2, p2, p3 as described
>>>>>>>> `odp_event_filter_packet()` would have RC = 3, the `packet[]` array
>>>>>>>> would contain p1, p2, p3, and the `remain[]` event would contain np1,
>>>>>>>> np2. Is that behavior what we want?
>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>> Even with the `odp_event_type_multi()` API semantics, it's still not
>>>>>>>>> clear why this is needed. Given that `odp_packet_from_event()` is
>>>>>>>>> likely just a cast there doesn't seem to be a great deal to be gained
>>>>>>>>> by having a `multi` version of this which can't be easily inlined
>>>>>>>>> away.
>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>> Again since `odp_packet_to_event()` is likely to be just a cast that
>>>>>>>>>> can be inlined away it's not clear why a `multi` version is needed.
>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>> Again, it's not clear why this is needed.
>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>> Not clear why this is needed. How does an application determine
>>>>>>>>>>>> this more efficiently than the implementation would?
https://github.com/Linaro/odp/pull/318#discussion_r154608403
updated_at 2017-12-04 10:23:18
