It's an implementation decision as to how to store metadata. Some implementations may choose to store it in hidden buffer prefixes or suffixes while others may choose to store it elsewhere. The linux-generic implementation is an example of the latter. The reason for doing it this way is that this allows the application full control over the alignment of the buffer data it deals with since that area isn't being used also for metadata, and means that metadata can be added or removed as the APIs evolve without affecting other data alignments.
On Tue, Jan 20, 2015 at 9:11 AM, Jerin Jacob <[email protected] > wrote: > On Mon, Jan 19, 2015 at 10:17:22AM -0600, Bill Fischofer wrote: > > 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. > > ODP_CONFIG_PACKET_BUF_LEN_MIN has special hardware constraints(like size > should be > multiple of cache line size etc). If we are changing the > ODP_CONFIG_PACKET_BUF_LEN_MIN > to hold the equations the it will create hole(unused space in buffer) for > no reason. For example, if > segment specific meta data is 8 bytes and cache size 128 byte..in this > case each buffer will waste > around 120 bytes. > > > > > > > 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
