muvarov 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:
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_r154597327
updated_at 2017-12-04 09:40:28
