See comments inline
On Mon, Sep 1, 2014 at 1:39 AM, Wiles, Roger Keith <
keith.wi...@windriver.com> wrote:
>
>
> I did not mean to imply the data needed to be contiguous or not, all I was
> trying to suggest constraints around the design for ODP. If that was
> unclear in my email then I am sorry about that.
>
> All I was trying to say is we can remove the restriction for persistent
> data, if that gets us moving forward. The last part of my email was to try
> and put some constraints around the design for the platform and 8 bytes
> seems to be the least amount of meta data we can require the platform to
> support. The reason I also spoke about a cache line size was to make sure
> we that cache line thrashing did not occur between CPUs trying to modify
> the same cache line, which is a big performance hit in most systems.
>
Yes, cache organization is a performance consideration on most systems,
which is precisely why ODP puts that onus on the implementation. The
alternative is either to ask that the application be aware of the
differences across platforms, which defeats the portability goals of ODP,
or else take at a one-size-fits-all approach that's unlikely to perform
well across all platforms. By letting the implementation handle these
things we get both application portability as well as good fit to each
platform.
>
> Suggesting the page size to be the max memory size for a platform is to
> make the designs simpler and not require huge amount of data to be managed
> by the platform. If the application needs more then the page size then they
> will have to handle the problem in the application. Also the platform could
> limit the max size to 8 bytes or cache line size if more memory becomes a
> problem. The down side is the application then must have a fallback
> solution if on one platform he has enough memory and another does not. That
> was my reason for defining a min/max require meta data to supported by the
> platform.
>
Every limit we place means that there's less value provided by ODP for
applications. It's a judgement call, but if we expect many representative
applications to require feature X then it's better to ask implementations
to provide that feature in a manner optimal to each platform rather than to
require the application to do it on its own and miss out on whatever
platform-specific optimizations might be possible. In the case of user
meta data the consensus has been that this feature is useful and if the
choice is between the application allocating/managing a block of per-packet
storage and asking the implementation to do this, then it's better to ask
the implementation to do this since at worse there will be no performance
difference and it's less work for the application, which encourages ODP
attractiveness. More likely, implementations will do a better job at this
than a portable application could since it is better positioned than the
application to know how to map ODP features to its platform in an optimal
manner.
> If we give too many option applications will not be portable for any
> platform.
>
Yes, that's the reason why we decided to make user meta data a MUST rather
than an OPTIONAL feature. We decided that user meta data persistence is
OPTIONAL since the consensus was that while it was useful for some
applications the implementation of that feature might impose an undue
burden on some platforms.
>
> I see the following requirements:
> - Meta-data is optional per platform. (I do not like this requirement,
> but trying to flexible here).
- If we can require all platforms to support meta-data it would make
> things simpler from ODP application design.
>
That was the original proposal that was rejected by the group. User meta
data now MUST be supported, so we're on your simpler point.
> - Min size of meta-data is 8 bytes or maybe it is a cache line, which
> ever one we decide.
The minimum size an application can request is 1 byte. The implementation
is free to round that up to whatever size makes sense since the application
requested size is returned as part of odp_buffer_udata().
> - Max size of meta-data is X and we can decide on what X is in this case.
> - If we use a page size that seems like more then enough space IMO.
> - If the application needs more then a page size then he must supply
> the design himself.
>
We debated that and rejected it as unnecessary. If an application can
allocate a block of memory and store a pointer to it than the
implementation can do that just as easily. Why burden the application?
This isn't to say that if an application requests a large amount of user
meta data that there won't be a performance impact to that request, but
that's a trade-off the application can make.
> - Persistent data is not required for meta-data support.
>
Correct, that is the current consensus. Persistence is an OPTIONAL feature.
Bill
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
