On Thu, Feb 23, 2017 at 6:56 AM, Verma, Shally <[email protected]> wrote:
> > > > > *From:* Bill Fischofer [mailto:[email protected]] > *Sent:* 23 February 2017 18:17 > *To:* Verma, Shally <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [lng-odp] odp_buffer_t usage > > > > > > > > On Thu, Feb 23, 2017 at 6:28 AM, Verma, Shally <[email protected]> > wrote: > > > > > > *From:* Bill Fischofer [mailto:[email protected]] > *Sent:* 23 February 2017 17:51 > *To:* Verma, Shally <[email protected]> > *Cc:* [email protected] > *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. > Yes, that is correct. > > > 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. > You can only pass an odp_buffer_t to ODP APIs whose type signatures are specified to accept odp_buffer_t inputs. Or are you talking about proposing adding a new ODP API? > > > 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 <[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 > > > > >
