Accessing another segment is an implicit release of the first, as is disposition of the packet via a queue operation. The reason for not over-specifying these sort of behaviors is to give the implementation maximum flexibility in how it wishes to implement APIs. If we had an explicit release call then that would require the implementation to wait until it received such a call before doing anything (and would have to deal with the case where an application forgets to issue one). I'd think that would impose a greater burden on implementations.
I gather from your remarks that your chip has a more NUMA-like addressing structure? If yes, I'd be very interested in ensuring that these APIs work well for you as accommodating that sort of architecture is the intent behind them. On Tue, Aug 26, 2014 at 8:12 AM, Gilad Ben Yossef <[email protected]> wrote: > > 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
