On Mon, Jan 19, 2015 at 10:17:22AM -0600, Bill Fischofer wrote: > On Mon, Jan 19, 2015 at 10:00 AM, Jerin Jacob < > jerin.ja...@caviumnetworks.com> 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 < > > jerin.ja...@caviumnetworks.com > > > > 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 < > > > > jerin.ja...@caviumnetworks.com > > > > > > 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 < > > > > > > > jerin.ja...@caviumnetworks.com> 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 > > > > > > > > lng-odp@lists.linaro.org > > > > > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > > > > > > > > > _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
