On 01/19/2015 09:17 AM, Jerin Jacob wrote: > On Sun, Jan 18, 2015 at 12:22:12AM +0200, Taras Kondratiuk wrote: >> On 01/17/2015 01:29 PM, Jerin Jacob wrote: >>> odp_packet_seg_t is an opaque type, based on the implementation, the return >>> value of odp_packet_last_seg can be changed after headroom/tailroom >>> push/pull >>> operation. >> >> No. By definition headroom/tailroom push/pull operations don't change >> segmentation. So the last segment must remain the same. > > For cavium, odp_packet_seg_t pretty much defined by the hardware spec > (its next seg data addr and data size of the next segment) so obviously > size of the segment will change after the tailroom push/pull operation. > > If odp specification demands for same seg handle value then I need to map it > as pointer which > points to the value. But its adds additional overhead for no good and even if > we make > it as pointer, it will fail in case of odp_packet_del_data. > > IMO, enforcing applications to not cache the odp_packet_seg_t for > headroom/tailroom push/pull and odp_packet_add/del_data will give freedom to > implementation to map best odp_packet_seg_t for the hardware.
While push/pull can't change segmentation odp_packet_add/del_data API *can* do this. They explicitly return a new odp_packet_t handle. To allow push/pull operations to change segmentation they also should have a way to return a new packet handle, because data can be copied to another packet. Anyway if you want to do these change then specification should be updated first. _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
