On Mon, Jan 19, 2015 at 10:00 AM, Jerin Jacob < [email protected]> wrote:
> On Mon, Jan 19, 2015 at 09:26:08AM -0600, Bill Fischofer wrote: > > On Mon, Jan 19, 2015 at 7:22 AM, Jerin Jacob < > [email protected] > > > wrote: > > > > > On Mon, Jan 19, 2015 at 06:09:34AM -0600, Bill Fischofer wrote: > > > > I think Petri should weigh in on these questions. For the first one, > > > what > > > > problems do you anticipate some platforms having with that equation? > > > > > > I have two issues around the unit test case, > > > 1) packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > ODP_CONFIG_PACKET_HEADROOM > > > - > > > ODP_CONFIG_PACKET_TAILROOM creates two segments in my platform and > > > tailroom/headroom expects > > > to work within a segment ? > > > > > > > Can you elaborate on why this is the case? The intent here was to define > > what constituted a single segment so if it's not accomplishing that goal > it > > would be useful to understand why not. > > OK. We have segment specific meta data(as I mentioned in beginning of the > mail thread) > in each segment that can't be counted in > ODP_CONFIG_PACKET_HEADROOM and/or ODP_CONFIG_PACKET_TAILROOM. > If it's metadata then is doesn't come out of either of these. Regardless of how a platform stores metadata it is not addressable by the application as part of the packet and hence not included in ODP_CONFIG_PACKET_BUF_LEN_MIN. So the equation should still hold. You're articulating why applications neither know nor care about physical segment sizes used by implementations. The only thing applications can see are the logical segments exposed by the ODP APIs. > > > > > > > > > > 2) pool creation with number of buffers as one and creating a segmented > > > buffers as > > > packet_len is more than one segment. > > > > > > > A packet (I use that term here since in our current definition only > packets > > can support segmentation or headroom) is an object that consists of > packet > > metadata plus packet data. Packet data is stored in one or more > segments, > > depending on how the pool it is allocated from is created, but > independent > > of the number of segments used to store this data it is still a single > > packet. So num_bufs (which will presumably be num_packets in the new > pool > > definitions) always has a precise meaning. > > but it has to be num_bufs == num_packet segments And why is that? They are logically different concepts. Conflating them only leads to confusion. > > > > > > > > > > > > > > > I think the cleanest solution would be to have the platform segment > size > > > > for a given pool accessible as pool metadata, e.g., > > > > odp_pool_seg_size(pool), but the real issue is why does the > application > > > > want this information? If an application wants to ensure that > packets > > > are > > > > unsegmented then the simplest solution is to re-introduce the notion > of > > > > unsegmented pools. If an application creates an unsegmented pool > then by > > > > definition any object allocated from that pool will only consist of a > > > > single segment. By contrast, if the application is designed to > support > > > > segments then it shouldn't care. > > > > > > IMO, its simple to add a ODP_CONFIG or odp_packet_alloc of len == 0 for > > > default packet size > > > > > > > ODP_CONFIG is how we're doing things now. More specific configurations > > should be doable on a per-pool basis (subject to implementation > > restrictions) given an expanded odp_pool_param_t definition. > > > > > > > > > > > > > > > On Mon, Jan 19, 2015 at 3:27 AM, Jerin Jacob < > > > [email protected] > > > > > wrote: > > > > > > > > > On Sat, Jan 17, 2015 at 09:45:12AM -0600, Bill Fischofer wrote: > > > > > > Application-visible sizes refer to application-visible data. > > > Metadata is > > > > > > always implementation-specific and not included in such counts. > > > Metadata > > > > > > is "off books" data that is associated with the packet but is not > > > part of > > > > > > any addressable packet storage. The advantage of having a packet > > > object > > > > > is > > > > > > that the packet APIs can refer to the packet independent of any > > > > > > implementation and not to how the packet may be represented in > > > storage > > > > > on a > > > > > > particular platform. > > > > > > > > > > But coming back to my question, How an application can create a one > > > segment > > > > > full length packet ? > > > > > Following equation may not be correct in all platforms > > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > > ODP_CONFIG_PACKET_HEADROOM - > > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > > > > > > > > > > > > > Trying to reason about buffers that are used to store packet > data is > > > > > > inherently non-portable and should be discouraged. Hopefully the > > > switch > > > > > to > > > > > > events will help move us in that direction since packets are no > > > longer a > > > > > > type of buffer using the new nomenclature. > > > > > > > > > > Should we remove odp_buffer_size(buf) == odp_packet_buf_len(pkt)) > test > > > > > case > > > > > or wait for event rework to happen ? > > > > > > > > > > > > > > > > > On Sat, Jan 17, 2015 at 5:52 AM, Jacob, Jerin < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Some odp_packet API queries based on exiting odp packet unit > test > > > case, > > > > > > > > > > > > > > 1) In exiting odp packet unit test case, In order to create one > > > full > > > > > > > length packet in one segment, > > > > > > > We have used following formula, > > > > > > > packet_len = ODP_CONFIG_PACKET_BUF_LEN_MIN - > > > > > ODP_CONFIG_PACKET_HEADROOM - > > > > > > > ODP_CONFIG_PACKET_TAILROOM; > > > > > > > > > > > > > > This may not be valid in all platform if the packet segment has > > > segment > > > > > > > specific meta data. > > > > > > > I think, we need to create either new ODP_CONFIG to define the > > > default > > > > > > > packet size > > > > > > > or odp_packet_alloc of len == 0 can be used to create default > > > packet > > > > > size. > > > > > > > > > > > > > > 2) If buffer is NOT aware of segmentation then > > > odp_buffer_size(buf) of > > > > > > > packet should be ODP_CONFIG_PACKET_BUF_LEN_MIN > > > > > > > instead of odp_buffer_size(buf) == odp_packet_buf_len(pkt)) . > > > > > > > > > > > > > > Any thoughts ? > > > > > > > > > > > > > > - Jerin > > > > > > > _______________________________________________ > > > > > > > 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
