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 ? 2) pool creation with number of buffers as one and creating a segmented buffers as packet_len is more than one segment. > > 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 > > 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
