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
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
