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. > > > > > 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 > > > > > > > > > > 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
