See response inline
On Tue, Sep 9, 2014 at 4:06 AM, Savolainen, Petri (NSN - FI/Espoo) <
[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.
>
> 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.
> >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
}
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
