| Message ID | 1400087120499.87673@caviumnetworks.com |
|---|---|
| State | New |
| Headers | show |
On 05/14/2014 08:05 PM, Rosenboim, Leonid wrote: > A common way to define an integer to be the same size as a native > pointer is: > > > typedef unsigned long odp_buffer_t; > > > This will make the type capable of containing either an index to a > table, or a pointer to an implementation-specific structure. odp_buffer_t may not always be a size of pointer. I can't imagine why someone may want odp_buffer_t to be 32-bit on 64-bit machine, but I prefer to have this possibility. > Another, more opaque alternative would be: > > > typedef struct udp_plat_buffer_s *odp_buffer_t; > > > This hides the details of the structure in the application code, but > forces the ID type to be a pointer, without allowing the application to > de-reference such a pointer and freeing the application of the need to > have the definition of the platform-specific structure.
If you assume a HW buffer manager then odp_buffer_t might be just an index value used to access HW structures. In such cases it's entirely possible the HW uses 32-bit indices even if the CPUs use 64-bit addressing. The advantage of an opaque type is that the application neither knows nor cares how the underlying implementation chooses to represent them. It's only interaction is via well-defined operations that don't expose the internals. On Thu, May 15, 2014 at 2:43 AM, Taras Kondratiuk < taras.kondratiuk@linaro.org> wrote: > On 05/14/2014 08:05 PM, Rosenboim, Leonid wrote: > >> A common way to define an integer to be the same size as a native >> pointer is: >> >> >> typedef unsigned long odp_buffer_t; >> >> >> This will make the type capable of containing either an index to a >> table, or a pointer to an implementation-specific structure. >> > > odp_buffer_t may not always be a size of pointer. I can't imagine why > someone may want odp_buffer_t to be 32-bit on 64-bit machine, but I prefer > to have this possibility. > > > Another, more opaque alternative would be: >> >> >> typedef struct udp_plat_buffer_s *odp_buffer_t; >> >> >> This hides the details of the structure in the application code, but >> forces the ID type to be a pointer, without allowing the application to >> de-reference such a pointer and freeing the application of the need to >> have the definition of the platform-specific structure. >> > > -- > Taras Kondratiuk > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
On 15 May 2014 04:05, Bill Fischofer <bill.fischofer@linaro.org> wrote: > If you assume a HW buffer manager then odp_buffer_t might be just an index > value used to access HW structures. In such cases it's entirely possible > the HW uses 32-bit indices even if the CPUs use 64-bit addressing. The > advantage of an opaque type is that the application neither knows nor cares > how the underlying implementation chooses to represent them. It's only > interaction is via well-defined operations that don't expose the internals. > > > On Thu, May 15, 2014 at 2:43 AM, Taras Kondratiuk > <taras.kondratiuk@linaro.org> wrote: >> >> On 05/14/2014 08:05 PM, Rosenboim, Leonid wrote: >>> >>> A common way to define an integer to be the same size as a native >>> pointer is: >>> >>> >>> typedef unsigned long odp_buffer_t; And technically, above is not always correct it assumes that LP64 memory model used in 64 bit. In LLP64 (P64) memory model 'unsigned long' is 32bit and it is different from pointer size. For example P64 memory model is used by Windows and in some cases by certain products running on top of Linux. The right way to have integer size capable of holding pointer is to use uintptr_t type. Thanks, Victor >>> >>> >>> This will make the type capable of containing either an index to a >>> table, or a pointer to an implementation-specific structure. >> >> >> odp_buffer_t may not always be a size of pointer. I can't imagine why >> someone may want odp_buffer_t to be 32-bit on 64-bit machine, but I prefer >> to have this possibility. >> >> >>> Another, more opaque alternative would be: >>> >>> >>> typedef struct udp_plat_buffer_s *odp_buffer_t; >>> >>> >>> This hides the details of the structure in the application code, but >>> forces the ID type to be a pointer, without allowing the application to >>> de-reference such a pointer and freeing the application of the need to >>> have the definition of the platform-specific structure. >> >> >> -- >> Taras Kondratiuk >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
diff --git a/include/odp_buffer.h b/include/odp_buffer.h index d79e76d..8bdd573 100644 --- a/include/odp_buffer.h +++ b/include/odp_buffer.h @@ -29,7 +29,7 @@ extern "C" { /** * ODP buffer */ -typedef uint32_t odp_buffer_t; +typedef uint64_t odp_buffer_t; #define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */ diff --git a/include/odp_buffer_pool.h b/include/odp_buffer_pool.h index 9112489..0e01f8b 100644 --- a/include/odp_buffer_pool.h +++ b/include/odp_buffer_pool.h @@ -30,7 +30,7 @@ extern "C" { #define ODP_BUFFER_POOL_INVALID (0xffffffff) /** ODP buffer pool */ -typedef uint32_t odp_buffer_pool_t; +typedef uint64_t odp_buffer_pool_t; /** diff --git a/include/odp_packet.h b/include/odp_packet.h index f7014fb..cf5a199 100644 --- a/include/odp_packet.h +++ b/include/odp_packet.h @@ -24,7 +24,7 @@ extern "C" { /** * ODP packet descriptor */ -typedef uint32_t odp_packet_t; +typedef uint64_t odp_packet_t; /** Invalid packet */ #define ODP_PACKET_INVALID ODP_BUFFER_INVALID