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
