Back to HTML… let’s see if it remains readable. From: ext Bill Fischofer [mailto:[email protected]] Sent: Tuesday, September 09, 2014 3:11 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: lng-odp-forward Subject: Re: [lng-odp] [ARCH DESIGN] Latest on persistent vs. non-persistent user meta data
See response inline On Tue, Sep 9, 2014 at 4:06 AM, Savolainen, Petri (NSN - FI/Espoo) <[email protected]<mailto:[email protected]>> wrote: This meta data copying from a source buffer to a destination buffer seems complex. How do you implement the copy if HW accelerator does not support it. Can you do it always (also when HW frees the src buffer automatically). Does it require extra hops into ODP SW (e.g. copy things out from the src buffer and back into the dst buffer between app and HW)? As noted in the doc, user meta data is either persistent or non-persistent and implementations MAY choose to implement only one of these types or both. If the copy requirement is awkward for a given implementation then it MAY choose to implement only persistent user meta data, in which case this problem (for the implementation) is avoided. Most implementations are expected to be a combination of HW and SW and trade offs are part of any design. It’s complex for the application also. Which one to choose, or #ifdef for both to remain portable. Should we just accept that - those two buffers are different, they hold different data (e.g. cipher text vs. plain text / outer packet (tunnel) headers vs. inner packet headers / etc ), and thus different meta data. - user must move its own metadata from old to new packet We can discuss this point during today's call. The question really is "what does the application need"? How commonly this copy is needed (HW allocate/free buffers automatically). Can application reproduce the packet context in other ways. How many cycles application saves if ODP does the copy instead of the app? Not too many, if it's just a pointer (a look up and save the pointer to the packet). The intent is that the implementation is required to do the copy when the application could not otherwise do so. For example, if an application is using non-persistent user meta data and calls odp_buffer_join() and the result is a new buffer returned (with the source buffers being freed by the implementation) then there would be no opportunity for the application to access the user meta data associated with buf1 after the join operation since that buffer is gone and along with it the user meta data it carried. Application could take a copy of the meta data before the call, and set it back to the new buffer after the call returns. >Second, to enable applications to know if they've been given a replacement >buffer upon return from calls that might do this, an explicit buffer comparison >call is introduced: > >int odp_buffer_is_same(odp_buffer_t buf1, odp_buffer_t buf2); > >that allows the caller to compare two buffer handles to determine if they are >the same. For most implementations this is expected to be a simple inlined >test >for equality (==) but is encapsulated in an API call because odp_buffer_t is an >opaque type. We cannot define a call (like this) that compares a handle from the past (buf1) to a handle in the present (buf2). When application enqueued (or freed or otherwise gave away a buffer handle) it cannot refer to it any more. Ownership of that handle is gone. An implementation may even ensure that by generation counting the handles. Another point to discuss during the call. I don't see why not. We're just comparing for determine if they changed, not if they point to a free or allocated buffer. The intent here is for an application to be able to do something like: odp_buffer_t my_source_buf = odp_buffer_alloc(...); odp_buffer_t my_result_buf = odp_buffer_operation(my_source_buf,...); if (odp_buffer_is_same(my_source_buf, my_result_buf) == 0) { ...copy any needed persistent user meta data from my_source_buf to my_result_buf } The time you notice that the buffer is not the same, the source_buf may have already freed/allocated/used for something else and the user context (meta data) modified (by another thread). -Petri
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
