On Wed, Jan 28, 2015 at 12:02:45PM -0500, Mike Holmes wrote: > Any resolution, I know there have been discussions on going but I need to > know if this is in 0.10.0
According to Petri, Application expects to reuse the seg handle after push/pull operations. so, No need to change the existing specification hence this patch is not applicable. validation: buffer: check the return value of odp_packet_l?_offset_set can be included in 0.10 > > On 27 January 2015 at 09:12, Mike Holmes <mike.hol...@linaro.org> wrote: > > > Can we resolve this for 0.10.0 > > > > On 25 January 2015 at 22:40, Jerin Jacob <jerin.ja...@caviumnetworks.com> > > 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 > >> lng-odp@lists.linaro.org > >> 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 lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
