Hi, Regarding the discussion about user meta data which was brought on during the conf, call, I thought I would try my hand at a short concise summary: - It is often useful to carry application specific meta data which is tied to a packet. - This application specific meta data is of application specific size - The application specific meta data life cycle is that of packet buffer allocation/release. - Because application meta data size is not known before hand, some platform will require a memory allocation for its storage space - On such platforms, it is useful to pre-allocate a per packet meta data memory and store a handle or pointer to it in each packet buffer at packet buffer creation. This has been referred to as packet buffer persistent meta data. - Such packet buffer persistent meta data life cycle is from that of packet buffer *pool* allocation/release. - As far as we can tell, storing the handle of packet meta data is the only use for packet buffer persistent meta data.
The current suggestion to handle this is, if I understand it correctly: - Have an API for requesting packet buffer persistent meta data at pool allocation time. - This API will be optional – so some platform may not implement it. - For those that will implement it, the packet buffer meta data (persistent or otherwise) will be of a variable platform specific size but no less than 8 bytes. I find the current suggestion very sub optimal since it does not take into consideration the needs of ODP application developers. Consider the following: I am an application creator. I require some meta data of size X and I chose ODP specifically to cover as many platforms as possible. What are my options? The platform I use may support meta data allocation of user meta data of the size I need. If not, the platform I use may still support allocation of persistent meta data so I can allocate a buffer for per packet user meta data and store that in the persistent meta data. If not, I need to implement my meta data in the form of a meta data "header" I add to packet data. Now, as application developer I either need to implement all 3 options OR implement fewer and be sub-optimal on some platforms or not be able to run on some.I believe this is bad for the application writer and the ODP eco system. Also note, that since the application writer ALWAYS has the option to allocate a buffer for its meta data and stuffing a pointer/handle to said buffer as a "meta header" in the packet, so does a platform ALWAYS an options to implement packet buffer meta data (just do what the application writer would have done… Therefore, I wish to suggest a different approach: 1. Application meta data will only be available to ODP_BUFFER_TYPE_PACKET buffers. 2. No persistent packet meta data will be supported in the API. 3. Application developer wishing to make use of packet meta data will specify how much user meta data they require at pool creation time, with a size limitation equal to the size limitation of the biggest buffer pool supported by the platform and a platform MAY perform needed initialization and allocation at this point. 4. Access to packet meta data will be done via an API, and a platform MAY perform allocation and initialization at first access time. 5. A generic implementation for allocating packet meta data buffers from an internal buffer pool and storing a pointer to said buffer as a "meta header" in the packet will provided as a helper function and any platform that does not provide a custom implementation MUST use this generic helper implementation as a default one. 6. A platform that is able to provide a better option to support this API, SHOULD do so. This helps ODP application writes because they now have a single way to ask for meta data and they trust the platform implementers to do the most efficient thing for their platform – as it should be. Also, any improvement in a platform implementation will help ALL ODP programs on that platform. What do you think? Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: [email protected]<mailto:[email protected]>, Web: http://www.ezchip.com<http://www.ezchip.com/> "Ethernet always wins." — Andy Bechtolsheim
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
