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