ODP pools provide an abstraction for various types of managed storage. There are currently three types of pools supported:
- ODP_POOL_BUFFER - ODP_POOL_PACKET - ODP_POOL_TIMEOUT A buffer pool is simply a collection of fixed-sized blocks represented by the odp_buffer_t abstraction. A packet pool stores packets represented by the odp_packet_t abstraction, which provide a rich set of semantics for manipulating packets. A timeout pool stores timeout events that are used as part of the timer management APIs. On Thu, Feb 23, 2017 at 12:42 AM, Verma, Shally <[email protected]> wrote: > Hi > > I was looking into odp_buffer_t to understand its use case from > Application stand point. While it is clear for odp_packet_t description > that it can be segmented/non-segmented contiguous / non-contiguous memory > and APIs are provided to query and hop across segments to access data, but > It is not clear how odp_buffer_t supposed to be allocated and accessed and > what App can use it for? As API set very minimalistic just to get address > and length of data. > > So, couple of questions comes : > > - Can ODP *Buffer* Pool be both linear / scatter-gather memory Or > it is always supposed to be one contiguous piece of memory? > Implementations are free to realize any ODP abstract type however they wish. There is no requirement that pools themselves be a single block of memory since individual buffers/packet/timeout objects are allocated and freed via their own APIs. Individual odp_buffer_t objects, however, are fixed-sized blocks of contiguous memory as segmentation is not part of the odp_buffer_t semantics. Every odp_buffer_t object contained in a buffer pool is the same size, as determined at odp_pool_create() time. > > - Is it safe to assume that memory of the type odp_buffer_t is > plain contiguous memory chunk (as malloc)? And data ptr retrieved through > odp_buf_addr() can be directly read/written. > Yes. odp_buffer_addr() returns a pointer to a contiguous memory area of size odp_buffer_size(), which is fixed for all odp_buffer_t objects drawn from the same pool. > > - If odp_buffer_t supposed to carry metadata info, then how user > know metadata len and actually data len? > The only metadata associated with an odp_buffer_t is it's size, obtained via the odp_buffer_size() API. > > - Is it valid to use odp_buffer_t in ODP API prototyping or they > are expected to use odp_packet_t ONLY? > Buffers and packets are different typed objects. Both can be converted to event types so they can be passed through queues that expect parameters of type odp_event_t, but the are not interchangeable. If an API expects an odp_packet_t as a parameter, attempting to pass an odp_buffer_t to it will be flagged as a type mismatch at compile time, as if you tried to pass an int to a routine that expected a char variable. > > Any info will be of help here. > Happy to help. If you have further questions, just ask. > > Thanks > Shally > >
