From: Bill Fischofer [mailto:bill.fischo...@linaro.org] Sent: 23 February 2017 18:17 To: Verma, Shally <shally.ve...@cavium.com> Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] odp_buffer_t usage
On Thu, Feb 23, 2017 at 6:28 AM, Verma, Shally <shally.ve...@cavium.com<mailto:shally.ve...@cavium.com>> wrote: From: Bill Fischofer [mailto:bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>] Sent: 23 February 2017 17:51 To: Verma, Shally <shally.ve...@cavium.com<mailto:shally.ve...@cavium.com>> Cc: lng-odp@lists.linaro.org<mailto: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? Each odp_buffer_t contained in a buffer pool is contiguous. It's up to the implementation, however whether the pool itself is a single contiguous block of storage as this is not specified by ODP. Sha>> So that implies to me that one single alloc request (odp_buffer_alloc()) should return a contiguous chunk ptr. Agreed and understood that Implementation can maintain pool anyways. The ODP crypto APIs operate on packet types, not buffer types, as the pkt and out_pkt fields of the odp_crypto_op_param_t struct that is passed to odp_crypto_operation() are of type odp_packet_t. Sha>> Crypto I took as an example to explain a use case which I am looking for or trying to enable. All I want to make sure that it is perfectly legal to input odp_buffer_t in ODP APIs and access them as contiguous memory. Note that while packets in ODP are composed of one or more segments, each implementation determines the segmentation model that it uses. Some implementations may only use a single segment for packets while others may use multiple segments (varying based on packet length). At odp_pool_create() time, the application simply indicates the minimum segment size it requires, however the implementation is free to use a larger segment size if that is more convenient for it. 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
