> From: Taras Kondratiuk [mailto:[email protected]] > Sent: Tuesday, August 26, 2014 2:40 PM > To: Gilad Ben Yossef > Cc: Bill Fischofer; lng-odp-forward > Subject: Re: [lng-odp] [ARCH DESIGN] Last call--Buffer Mgmt Design > > On 08/26/2014 02:01 PM, Gilad Ben Yossef wrote: ... > > > > 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. > > > IMO explicit API can be avoided. Application owns buffer until it is > pushed to some queue or consumed by implementation via some other API > (odp_pktio_send, etc). After that point application has no access to > the buffer, so any reserved resources can be cleaned up by > implementation.
I understand, but this comes at an enormous cost for implementations where buffer segments are not addressable. For example: an application may reference the address of 3 different buffer segments via an iterators. The application does not modify the content of any of the buffer segments, and it accesses them one by (e.g. uses the same variable to store the address of all 3 segments.). However, the implementation has no practical way to be aware of the above two facts, therefore - the Implementations is forced to reserve resource (e.g. portions of local core RAM) for all 3 segments as well as potentially write back these local copies back to original segments, even though it only really needed to allocate local resources for a single segment and never write it back. This really is a heavy ball and chain for such implementations. I hope there is a better way :-( Gilad _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
