On 12/08/15 11:40, Bill Fischofer wrote:
Some basic comments:
First, ODP buffers are never returned as addresses. Buffers are of
type odp_buffer_t, not void *.
Second, the purpose here is to initialize user metadata, not the
buffer (that's the responsibility of the implementation), and ODP only
defines user metadata for packets, not general buffers, so this init
is done for pools of type ODP_POOL_PACKET. So a better signature
might be:
Ok, I'm convinced, we don't need to support init of the buffer here.
typedef void (odp_packet_uarea_init_t)(odp_packet_t pkt, void
*uarea_init_arg, void *uarea);
and this would be activated via a new field in the odp_pool_param_t:
typedef struct odp_pool_param_t {
/** Pool type */
int type;
union {
struct {
/** Number of buffers in the pool */
uint32_t num;
/** Buffer size in bytes. The maximum number of bytes
application will store in each buffer. */
uint32_t size;
/** Minimum buffer alignment in bytes. Valid values are
powers of two. Use 0 for default alignment.
Default will always be a multiple of 8. */
uint32_t align;
} buf;
struct {
/** The number of packets that the pool must provide
that are packet length 'len' bytes or smaller. */
uint32_t num;
/** Minimum packet length that the pool must provide
'num' packets. The number of packets may be less
than 'num' when packets are larger than 'len'.
Use 0 for default. */
uint32_t len;
/** Minimum number of packet data bytes that are stored
in the first segment of a packet. The maximum value
is defined by ODP_CONFIG_PACKET_SEG_LEN_MAX.
Use 0 for default. */
uint32_t seg_len;
/** User area size in bytes. Specify as 0 if no user
area is needed. */
uint32_t uarea_size;
/** User area initializer. Specify as NULL if
initialization calls
are not needed */
odp_packet_uarea_init_t uarea_init;
/** User area initializer parameter. Ignored
unless user area
initializer is non-NULL */
void *uarea_init_arg;
} pkt;
struct {
/** Number of timeouts in the pool */
uint32_t num;
} tmo;
};
} odp_pool_param_t;
The semantics would be that at odp_pool_create() time, if a
uarea_init() routine is specified for the pool, then it is called for
each packet in the pool and is passed the handle of that packet, the
opaque uarea_init_arg specified on the odp_pool_param_t, and the
address of the user area associated with that packet (the size of that
area is fixed and presumably known to the initializer since it was
specified in the uarea_size field of the odp_pool_param_t).
One of the objections to callbacks voiced last year is that different
implementations may not be able to iterate through pool members as
implied by this. Since the intent here is to initialize the packet
user area, perhaps a more specific focus on that intent would be less
problematic.
I see. Does anyone know why a platform can't iterate through buffers at
pool creation time? If it's because they are allocated in memory on
deman, then the platform shouldn't call this at pool creation, but when
packet is allocated.
On Wed, Aug 12, 2015 at 5:09 AM, Zoltan Kiss <[email protected]
<mailto:[email protected]>> wrote:
On 12/08/15 07:34, Bala Manoharan wrote:
Hi,
Comments inline...
On 12 August 2015 at 00:01, Zoltan Kiss
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
Applications can preset certain parts of the buffer or
user area, so
when that
memory will be allocated it starts from a known state. If
the platform
allocates the memory during pool creation, it's enough to
run the
constructor
after that. If it's allocating memory on demand, it should
call the
constructor each time.
[Bala] Not sure if I understand the above description
correctly does it
mean that if the memory is allocated
for an existing pool this call should be called only during
the pool
creation and not during each and every buffer allocation?
Then it will be applications responsibility to reset the user area
before freeing the buffer? Is this the use-case this API is
trying to
address?
Signed-off-by: Zoltan Kiss <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
---
include/odp/api/pool.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h
index 2e79a55..1bd19bf 100644
--- a/include/odp/api/pool.h
+++ b/include/odp/api/pool.h
@@ -41,6 +41,20 @@ extern "C" {
#define ODP_POOL_NAME_LEN 32
/**
+ * Buffer constructor callback function for pools.
+ *
+ * @param pool Handle of the pool which owns the
buffer
+ * @param buf_ctor_arg Opaque pointer defined in
odp_pool_param_t
+ * @param buf Pointer to the buffer
+ *
+ * @note If the application specifies this pointer, it
expects that
every buffer
+ * is initialized with it when the underlying memory is
allocated.
+ */
+typedef void (odp_pool_buf_ctor_t)(odp_pool_t pool,
+ void *buf_ctor_arg,
+ void *buf);
+
[Bala] We have avoided call back functions in ODP architecture
so if the
requirement can be addressed without a call-back maybe we can
follow
that approach. Again I am not clear if this call-back function
should be
called only once during pool creation or every time during
buffer alloc.
Why is this fear from callbacks? I know it's breaking call graph
feature of Eclipse, but that's not a huge issue.
+/**
* Pool parameters
* Used to communicate pool creation options.
*/
@@ -88,6 +102,12 @@ typedef struct odp_pool_param_t {
uint32_t num;
} tmo;
};
+
+ /** Buffer constructor to initialize every buffer.
Use NULL
if no
+ initialization needed. */
+ odp_pool_buf_ctor_t *buf_ctor;
+ /** Opaque pointer passed to buffer constructor */
+ void *buf_ctor_arg;
} odp_pool_param_t;
/** Packet pool*/
--
1.9.1
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
https://lists.linaro.org/mailman/listinfo/lng-odp
Regards,
Bala
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
