Hi Bill and everyone, As this is my first post (a few patches not withstanding), I'd like to start by saying thank you for the work you and everyone are putting into ODP.
Now for the topic at hand - I know I am a bit of a Johnny-come-lately to this discussion and a new comer to ODP. I apologize therefore if some of these issues have been discussed in the past. The design docs specifies that " Applications cannot address the contents of a buffer or a buffer segment until they explicitly request addressability via the odp_buffer_addr(), odp_buffer_segment_addr(), or odp_buffer_offset_addr() calls. … The provision of this explicit step to make buffers and buffer segments addressable to an application is for NUMA architecture support since the actual memory area(s) that store buffers may not be directly addressable to application processing cores on such architectures". However, no API is provided to explicitly state that access to the segment is no longer needed, thus allowing freeing any resources required by making the segments available. Consider as an example an implementation where the odp_buffer_addr() installs a virtual to physical mapping by populating a hardware MMU register such as a TLB entry. Without an explicit point where the buffer data is no longer required to be addressable, there is no point for the implementation to release said entry. A similar issue exists if the implementation does not map the address but, for example, prefetch the data and locks cache lines of a local L1/2 cache. Another scenario is where the ECC or some other form of protection information is kept inband or out of band for packet buffer segments - and one wants to recalculate and update the checksum at the end of each segment being updated. Yet another scenario to consider is an implementation where buffer data is not addressable at via virtual memory and addressability is attained by a hardware engine performing a DMA copy to a local SRAM, modification in the local copy and than a DMA copy to global memory. And of course, any combinations and permutations of the above… In light of the above, I would be interesting to get your feedback on an API of the form: /* * Request a virtual address where the data of the buffer 'buffer' starting at offset 'offset' from beginning * of the buffer and of size 'len' mat be addressed. * Note that 'len' cannot exceed the buffer size * * The function may do any of the following: return the buffer globally visual virtual address, map a temporary * local virtual address to the buffer, prefetch the buffer data and possibly lock cache line used for the buffer * into cache or copy buffer data to a local RAM and return a virtual address to the copy. */ void * odp_buffer_get(odp_buffer_t buffer, ssize_t offset, ssize_t len) /* * Make any local changes to a mapped buffer globally visible * * The function may do any of the following: nothing, flush data cache, copy local copy * content to global buffer. * Note! Any changes to buffer content which are not flushed may be lost! */ void odb_buffer_flush(odp_buffer_t buffer, void * addr, ssize_t offset, ssize_t size) /* * Unmap the buffer, releasing any resources if any, which are used by the mapping * * The function may do any of the following: nothing, unlock cache line, free local RAM */ void odb_buffer_unmap(void * addr) /* * Flush than unmap the buffer * * Combo of flush + unmap */ void odb_buffer_release (odp_buffer_t buffer, void * addr, ssize_t offset, ssize_t size) Note that in a linux-generic implementation only the map function need to be implemented (identical to current odp_buffer_offset_addr()) while the rest of the APIs may be no-ops, BUT even for linux-generic we can easily do some smart things for debugging by implementing the other hooks (catch memory run overs, etc.) and of course for SoC with a more "interesting" notions I have a couple of more less essential comments, but I'd first would like to get your feedback regarding these ideas. Many thanks, Gilad 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 From: [email protected] [mailto:[email protected]] On Behalf Of Bill Fischofer Sent: Monday, August 25, 2014 8:30 PM To: lng-odp-forward Subject: [lng-odp] [ARCH DESIGN] Last call--Buffer Mgmt Design I've revved the buffer mgmt doc one more time to incorporate all of the comments and dialog over the past couple of weeks. I'd like to wrap this up during tomorrow's ODP call. Please see https://docs.google.com/a/linaro.org/document/d/1sleFBhG2E-TorClpaBHxOhRu0pA5e2l-JNAE732SRto/edit#<https://docs.google.com/a/linaro.org/document/d/1sleFBhG2E-TorClpaBHxOhRu0pA5e2l-JNAE732SRto/edit> for the proposed final version of this doc. Thanks. Bill
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
