Petri Savolainen(psavol) replied on github web page:

include/odp/api/spec/packet.h
line 13
@@ -204,6 +204,17 @@ void odp_packet_free(odp_packet_t pkt);
  */
 void odp_packet_free_multi(const odp_packet_t pkt[], int num);
 
+/**
+ * Free multiple packets to the same pool
+ *
+ * Otherwise like odp_packet_free_multi(), but all packets must be from the
+ * same originating pool.
+ *
+ * @param pkt           Array of packet handles
+ * @param num           Number of packets to free
+ */
+void odp_packet_free_sp(const odp_packet_t pkt[], int num);


Comment:
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_r154604104
updated_at 2017-12-04 10:05:31

Reply via email to