The issue is not whether the number of segments is changed but whether the pkt handle is changed. APIs that potentially substitute a new handle must return a handle. If a handle is not returned then the input handle is unchanged, however behavior of subsequent APIs against that handle may of course change. To take a trivial example, odp_packet_len() will obviously change following a push/pull even though the same handle is used.
I agree with Jerin that we really need to take care to not overspecify behavior on ODP APIs. API observable effects should be minimally specified to allow implementations latitude in how best to map the required behavior to their platform. In the case of push/pull the purpose is simply to add or subtract bytes at the start or end of a packet. That's the essential function of these APIs and is the only thing that should be specified as required behavior. In the case of segmentation there are two philosophies one can adopt. The first is that the application desires and needs to have explicit control over packet segmentation. The second is that any packet segmentation is the responsibility of the implementation and the application need only be aware that packets may be segmented and take that into account in its design, realizing that segments are the units of contiguous addressability. The former is a very software-centric view which provides limited opportunity for implementations to optimize performance, and may in fact be impossible to implement efficiently on some platforms. The latter requires that existing software-centric applications may need some more redesign to better adapt to ODP. But the benefits of such adaptation is cleaner portability across a wider range of platforms with optimal performance on each, and that's really the goal of ODP. On Sat, Jan 24, 2015 at 6:23 AM, Taras Kondratiuk < [email protected]> wrote: > 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 >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
