On 11-Jan-19 7:27 PM, Eads, Gage wrote:


-----Original Message-----
From: Richardson, Bruce
Sent: Friday, January 11, 2019 5:59 AM
To: Burakov, Anatoly <anatoly.bura...@intel.com>
Cc: Eads, Gage <gage.e...@intel.com>; dev@dpdk.org;
olivier.m...@6wind.com; arybche...@solarflare.com; Ananyev, Konstantin
<konstantin.anan...@intel.com>
Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width
size

On Fri, Jan 11, 2019 at 11:30:24AM +0000, Burakov, Anatoly wrote:
On 11-Jan-19 10:58 AM, Bruce Richardson wrote:
On Fri, Jan 11, 2019 at 10:40:19AM +0000, Burakov, Anatoly wrote:
<...>

+ * Copyright(c) 2016-2019 Intel Corporation
     */
    /**
@@ -88,7 +88,7 @@ rte_event_ring_enqueue_burst(struct
rte_event_ring *r,
                const struct rte_event *events,
                unsigned int n, uint16_t *free_space)
    {
-       uint32_t prod_head, prod_next;
+       uintptr_t prod_head, prod_next;

I would also question the use of uinptr_t. I think semnatically,
size_t is more appropriate.

Yes, it would, but I believe in this case they want to use the
largest size of (unsigned)int where there exists an atomic for
manipulating 2 of them simultaneously. [The largest size is to
minimize any chance of an ABA issue occuring]. Therefore we need
32-bit values on 32-bit and 64-bit on 64, and I suspect the best way
to guarantee this is to use pointer-sized values. If size_t is
guaranteed across all OS's to have the same size as uintptr_t it could also be
used, though.

/Bruce


Technically, size_t and uintptr_t are not guaranteed to match. In
practice, they won't match only on architectures that DPDK doesn't
intend to run on (such as 16-bit segmented archs, where size_t would
be 16-bit but uinptr_t would be 32-bit).

In all the rest of DPDK code, we use size_t for this kind of thing.


Ok.
If we do use size_t, I think we also need to add a compile-time check into the
build too, to error out if sizeof(size_t) != sizeof(uintptr_t).

Ok, I wasn't aware of the precedent of using size_t for this purpose. I'll 
change it and look into adding a static assert.

RTE_BUILD_BUG_ON?


Thanks,
Gage



--
Thanks,
Anatoly

Reply via email to