NikhilA-Linaro replied on github web page:
include/odp/api/spec/pool.h
line 48
@@ -163,79 +172,133 @@ typedef struct odp_pool_capability_t {
int odp_pool_capability(odp_pool_capability_t *capa);
/**
+ * Packet pool subparameters
+ */
+typedef struct odp_pool_pkt_subparam_t {
+ /** Number of 'len' byte packets. */
+ uint32_t num;
+
+ /** Packet length in bytes */
+ uint32_t len;
+
+} odp_pool_pkt_subparam_t;
+
+/**
* Pool parameters
- * Used to communicate pool creation options.
- * @note A single thread may not be able to allocate all 'num' elements
- * from the pool at any particular time, as other threads or hardware
- * blocks are allowed to keep some for caching purposes.
+ *
+ * A note for all pool types: a single thread may not be able to allocate all
+ * 'num' elements from the pool at any particular time, as implementations are
+ * allowed to store some elements (per thread and HW engine) for caching
+ * purposes.
Comment:
This limitation is implementation specific. Why API wants to impose a generic
limitation of APIs
> NikhilA-Linaro wrote
> 1. Traditionally a pool means - a fixed size memory chunks. In case of
> packet buffer pool, the buffers units are of single size. If you need packet
> buffer pools of different size, different packet buffers pools shall be
> attached to packet io or other entity.
> 2. These sub parameters will create ambiguity when application allocates
> different packets of different sizes. API needs to define the clear
> requirement in that case.
> 3. Providing info for SG allocations from application is implementation
> specific. I don't think this suits for a common data plane API.
https://github.com/Linaro/odp/pull/234#discussion_r148219575
updated_at 2017-11-01 09:55:26
