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

Reply via email to