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
