From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: 23 February 2017 17:51 To: Verma, Shally <shally.ve...@cavium.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] odp_buffer_t usage
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. >> So is it safe to assume implementation will always allocate a fixed-size >> *contiguous* block ? Can it be used to pass on plain bulk data? Example , if ODP Crypto is to encrypt a large data in a chunk size of 16K, where chunk is *not packet* type but need to be contiguous memory. Then is it legal to get a buffer of len 16k through odp_buffer_alloc() and passed to ODP Crypto for such use case? 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 <shally.ve...@cavium.com<mailto:shally.ve...@cavium.com>> 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
