I think there are many issues with binary compatibility beyond function inlining. An ODP application cannot expect all ODP implementations to support the same number of ODP queues or classification rules or even which classification terms (fields) are supported (efficiently/in HW) etc. Is there some kind of lowest common denominator an application should expect? Do we want to make guarantees of an ODP implementation stricter? What are the consequences of such strict functional guarantees?
I think an application that requires binary compatibility over ARMv8.1 platforms should compile and link against a specific ODP SW implementation (possibly with some well-defined HW offloads where the underlying platform can provide the relevant drivers). I.e. more of a (user-space) Linux architecture than standard ODP (as influenced by OpenGL). The important binary interfaces then becomes the interfaces to these offloads/drivers. On 16 November 2015 at 14:23, Nicolas Morey-Chaisemartin <nmo...@kalray.eu> wrote: > > > On 11/11/2015 09:45 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote: >> >>> -----Original Message----- >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >>> EXT Nicolas Morey-Chaisemartin >>> Sent: Tuesday, November 10, 2015 5:13 PM >>> To: Zoltan Kiss; linaro-toolchain@lists.linaro.org >>> Cc: lng-odp >>> Subject: Re: [lng-odp] Runtime inlining >>> >>> As I said in the call last week, the problem is wider than that. >>> >>> ODP specifies a lot of types but not their sizes, a lot of >>> enums/defines (things like ODP_PKTIO_INVALID) but not their value >>> either. >>> For our port a lot of those values were changed for >>> performance/implementation reason. So I'm not even compatible between >>> one version of our ODP port and another one. >>> >>> The only way I can see to solve this is for ODP to fix the size of all >>> these types. >>> Default/Invalid values are not that easy, as a pointer would have a >>> completely different behaviour from structs/bitfields >>> >>> Nicolas >>> >> Type sizes do not need to be fixed in general, but only when an application >> is build for binary compatibility (the use case we are talking here). Binary >> compatibility and thus the fixed type sizes are defined per ISA. >> >> We can e.g. define a configure target (for our reference implementation == >> linux-generic) "--binary-compatible=armv8.x" or >> "--binary-compatible=x86_64". When you build your application with that >> option, "platform dependent" types and constants would be fixed to >> pre-defined values specified in (new) ODP API arch files. >> >> So instead of building against >> odp/platform/linux-generic/include/odp/plat/queue_types.h ... >> >> typedef ODP_HANDLE_T(odp_queue_t); >> #define ODP_QUEUE_INVALID _odp_cast_scalar(odp_queue_t, 0) >> #define ODP_QUEUE_NAME_LEN 32 >> >> >> ... you'd build against odp/arch/armv8.x/include/odp/queue_types.h ... >> >> typedef uintptr_t odp_queue_t; >> #define ODP_QUEUE_INVALID ((uintptr_t)0) >> #define ODP_QUEUE_NAME_LEN 64 >> >> >> ... or odp/arch/x86_64/include/odp/queue_types.h >> >> typedef uint64_t odp_queue_t; >> #define ODP_QUEUE_INVALID ((uint64_t)0xffffffffffffffff) >> #define ODP_QUEUE_NAME_LEN 32 >> >> >> For highest performance on a fixed target platform, you'd still build >> against the platform directly >> >> odp/platform/<soc_vendor_xyz>/include/odp/plat/queue_types.h >> >> typedef xyz_queue_desc_t * odp_queue_t; >> #define ODP_QUEUE_INVALID ((xyz_queue_desc_t *)0xdeadbeef) >> #define ODP_QUEUE_NAME_LEN 20 >> >> >> -Petri >> > > It still means that you need to enforce a type for all ODP implementation on > a given arch. Which could be problematic. > As a precise example: the way handles are used now for odp_packet_t brings > some useful features for checks and memory savings, but performance wise, > they are a "disaster". One of the first thing I did was to switch them to > pointers. And if I wanted a high perf linux x86_64 implementation, I'd > probably do the same. > > Nicolas > _______________________________________________ > lng-odp mailing list > lng-...@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
