Any resolution, I know there have been discussions on going but I need to know if this is in 0.10.0
On 27 January 2015 at 09:12, Mike Holmes <[email protected]> wrote: > Can we resolve this for 0.10.0 > > On 25 January 2015 at 22:40, Jerin Jacob <[email protected]> > wrote: > >> On Sun, Jan 25, 2015 at 03:01:24PM +0200, Taras Kondratiuk wrote: >> > On 01/24/2015 08:06 PM, Bill Fischofer wrote: >> > > 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. >> > >> > I agree on most of these items and I do understand Jerin's restrictions, >> > but my main point: current test does follow specification. If it can't >> > be implemented efficiently on a platform, then specification should be >> > changed first. >> >> OK, How about following change in the specification ? >> >> diff --git a/platform/linux-generic/include/api/odp_packet.h >> b/platform/linux-generic/include/api/odp_packet.h >> index 920a593..e418e42 100644 >> --- a/platform/linux-generic/include/api/odp_packet.h >> +++ b/platform/linux-generic/include/api/odp_packet.h >> @@ -244,7 +244,7 @@ void *odp_packet_tail(odp_packet_t pkt); >> * headroom -= len >> * data -= len >> * >> - * Operation does not modify packet segmentation or move data. Handles >> and >> + * Operation does not modify packet segmentation or move data. pkt >> handle and >> * pointers remain valid. User is responsible to update packet metadata >> * offsets when needed. >> * >> @@ -272,7 +272,7 @@ void *odp_packet_push_head(odp_packet_t pkt, uint32_t >> len); >> * headroom += len >> * data += len >> * >> - * Operation does not modify packet segmentation or move data. Handles >> and >> + * Operation does not modify packet segmentation or move data. pkt >> handle and >> * pointers remain valid. User is responsible to update packet metadata >> * offsets when needed. >> * >> @@ -302,7 +302,7 @@ void *odp_packet_pull_head(odp_packet_t pkt, uint32_t >> len); >> * tail += len >> * tailroom -= len >> * >> - * Operation does not modify packet segmentation or move data. Handles, >> + * Operation does not modify packet segmentation or move data. pkt >> handle, >> * pointers and offsets remain valid. >> * >> * @param pkt Packet handle >> @@ -331,7 +331,7 @@ void *odp_packet_push_tail(odp_packet_t pkt, uint32_t >> len); >> * tail -= len >> * tailroom += len >> * >> - * Operation does not modify packet segmentation or move data. Handles >> and >> + * Operation does not modify packet segmentation or move data. pkt >> handle and >> * pointers remain valid. User is responsible to update packet metadata >> * offsets when needed. >> * >> >> >> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > > -- > *Mike Holmes* > Linaro Sr Technical Manager > LNG - ODP > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
